I actually did have a look at it. Actually, I think using it will be much harder for the connectors - at least using that API. I suppose it might be possible to use it as the implementation behind the current API, but the current API is really much friendlier.

Other than the memory management aspects (which I understand, and which might be why we might want to use it in some places) are there any functionality bits we could benefit from that we can't do with the current API?

Here's where it gets difficult. As I understand it, with the NdbRecord API, if I want to fetch a varchar(32) and int and a datetime from a table, I need to allocate a single, appropriately size buffer and hand that to NdbRecord. The API will then populate the buffer, and I am then free to read the contents of the buffer as I choose, and free it when I'm done. Which is great, if I'm MySQL. But what if I'm writing from Python? (Or even Java) What do I pass to that function? Do I just get back a List of bytes? It's a sort of fascinating thing to think about, because the answer is not as obvious to me as wrapping the more OO old API. (And I hope, for this reason, you'll overlook my stream-of-consciousness ramblings here)

So, I've been merging the NDB/J stuff this last week, and let me tell you what would actually be really useful from the connectors point of view - NDB/J supports the following:

NdbOperation foo = transaction.getNdbOperation("table"); foo.readTuple(NdbTransaction.LockMode.LM_Read); foo.equal("id",12); // Notice - no recattrs returned here foo.getString("name"); foo.getLong("age"); // people can be very old foo.execute(NdbTransaction.ExecType.Commit); NdbResultSet results = foo.getResutSet();

which makes for good programming. Right now, I'm faking this in Java. My getString and getLong methods are just wrappers around NdbOperation::getvalue() which store the RecAttr in a Map<String,NdbRecAttr> belonging to the NdbOperation. Of course, this is sort of silly, since on the C++ level the NdbOperation object already owns the memory for the RecAttrs and probably has a private list of them. So if I could just have a method (or two) on NdbOperation that would let me get the RecAttrs owned by the Operation, I could do all of this ResultSet stuff in the mapping layer rather than in the Java wrapper layer. If we had that, we could even implement something like NdbResultSet in the API...

And thus we reach the quandry that we will always reach - needs of Application programmers and System programmers. I'm totally on board with all the non-memory-copying we get from NdbRecord and how wonderful that is.

Stewart Smith wrote: