Mika Raento wrote:
> Had time to look into NDB again. I have a couple of things I'd like to
> add to the perl bindings that I assume are interesting for other
> languages as well, but most likely should be implemented in the target
> 1. Strings given to NdbOperation::equal(char*, char*) need to be
> length-prefixed. So something like 'shard_uuid' needs to become
Yes. I have this working in Python. We could do this in C at the swig
layer, which is probably where is should be done, as we could probably
do it better there. Don't forget, too, that if the string is >256 bytes
it gets a two-byte length prefix.
The real fun part, of course, is that this is only the case for varchar
columns. For char columns, we need to space-pad the end of the string
out to the column width. Except that from a programming perspective,
strings are strings. So I'm not really sure how to design this right. Do
we make people instantiate a Varchar() or a Char() in their code? I
think that would be very ugly - maybe ok in Java.
Maybe we should load the data dictionary at initialization time and have
our wrappers for equal and setValue for char* types do a lookup in the
data dictionary on the column type and either space pad char columns or
add length to the varchar columns. That could all be done once in C++ in
the swig file and taken advantage of by all the languages. Sound
reasonable? Then, perhaps, we could make an NdbVarchar and an NdbChar
type that you could instantiate and pass in if you want to avoid the
data dictionary step. But if we load the dictionary at init time, the
API caches it, so it really shouldn't be too much of a hit in the
context of a calling Perl or Python program.
> 2. You should close all transactions. I would like to have something
> akin to auto_ptr<> for that: wrap the transaction in a native language
> object that closes it unless it has been explicitly released. This
> provides for exception safe releases of transactions.
> I'm not even sure where I should write this code so that it integrates
> with the swig-created classes, let alone what's the best way to
> structure it.
Hmm. Good point. We could do that in each language, which might be the
only way to do it sensibly. But perhaps we can actually do an extension
to Ndb::getTransaction to have it return an auto_ptr<> instead? Or
something - I'll go do some digging into if there is a swig best
practice for adding a wrapper-destructor that could call close on the
wrapped object when the wrapping object gets reaped.
MySQL Inc., www.mysql.com
Get More with MySQL! www.mysql.com/consulting