Smalltalk › Pharo › Pharo Smalltalk Users

[Voyage] Using OID as a domain object identifier

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Esteban A. Maringolo

[Voyage] Using OID as a domain object identifier

Hi all,

Is it a good practice to use the OID value (anInteger) as an
"external" identifier of your domain object?

Let's suppose I have a collection of "People", as I save them in the
collection, it will automatically create OIDs for them.

But let's suppose I want to map that person to a RESTful URI, would it
be "legal" to use its OID as part of the URI?

E.g. mydomain.com/people/123456790
where 123456790 is the OID value.

I like OID/UUIDs, and I don't want to duplicate that logic in my app.

Regards,

Esteban A. Maringolo

NorbertHartl

Re: [Voyage] Using OID as a domain object identifier

Am 29.07.2013 um 15:46 schrieb "Esteban A. Maringolo" <[hidden email]>:

> Hi all,
>
> Is it a good practice to use the OID value (anInteger) as an
> "external" identifier of your domain object?
>
> Let's suppose I have a collection of "People", as I save them in the
> collection, it will automatically create OIDs for them.
>
> But let's suppose I want to map that person to a RESTful URI, would it
> be "legal" to use its OID as part of the URI?
>
> E.g. mydomain.com/people/123456790
> where 123456790 is the OID value.
>
> 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.

Norbert

Esteban A. Maringolo

Re: [Voyage] Using OID as a domain object identifier

2013/7/29 Norbert Hartl <[hidden email]>:
> Am 29.07.2013 um 15:46 schrieb "Esteban A. Maringolo" <[hidden email]>:
>> 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...

Regards,

Esteban A. Maringolo

NorbertHartl

Re: [Voyage] Using OID as a domain object identifier

Am 29.07.2013 um 19:34 schrieb Esteban A. Maringolo <[hidden email]>:

2013/7/29 Norbert Hartl <[hidden email]>:
Am 29.07.2013 um 15:46 schrieb "Esteban A. Maringolo" <[hidden email]>:
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