Am 29.07.2013 um 19:34 schrieb Esteban A. Maringolo <emaring...@gmail.com>:
> 2013/7/29 Norbert Hartl <norb...@hartl.name>: >> Am 29.07.2013 um 15:46 schrieb "Esteban A. Maringolo" <emaring...@gmail.com>: >>> Is it a good practice to use the OID value (anInteger) as an >>> "external" identifier of your domain object? >>> ... >>> I like OID/UUIDs, and I don't want to duplicate that logic in my app. >>> >> I think for your purpose OID will be fine but I'm not sure. I use UUIDs. You >> can instruct mongo to use a UUID instead of an OID. Works flawlessly. > > How do you do that? Because OID's are a BSON native artifact, > efficient in terms of storage and lookup (a 12 byte integer in the > end...) > > Is there a way to have an smaller UUID? more like the first eight > chars of a Git commit or similar… If you look at [1] you can see that UUID is a native BSON artefact as well. Pharo has a UUID class. I extended the Mongo driver to serialize UUID properly. So basically all you need is to put a UUID object in your model object and serialization should be automatic. Of course you need to tell the serialization layer to serialize it as _id. But it is fully supported on mongo. Performance wise it is said it might be a tad slower than object ids. But if you have doubts about object ids you should be willing to take the payoff. I can't help here much because I have my own serialization layer that is pretty much superseded by Voyage. Do you have really performance problems why you like to restrict the key size? That would be a bad because you would restrict the uniqueness to a useless artefact. IIRC mongo does that for you anyway. There is a certain size of key mongo evaluates first and rechecks on collision. But I'm not sure I had only the impression the same techniques are in charge as for other hashing problems. hope this helps, Norbert [1] http://bsonspec.org/#/specification
