[Nitro] Og UUIDs

Jonathan Buch john at oxyliquit.de
Wed Apr 25 04:16:45 EDT 2007


> it is a bit difficult to follow (and reply to) emails these days, but  
> let me try...

sure, concentrate on your wedding, real decisions can wait.  :)

> One of the ideas of the new version of Nitro/Og is to reuse standard Ruby
> idioms (like modules). There is an Og option that automatically includes  
> the UUID mixin to your classes (this is what I use). But i think:
> class MyModel
>   include UUIDPrimaryKey
> end
> is very readable. I could handle the notation you suggest but I don't  
> really see the point to add this custom behaviour when the standard
> ruby idiom is more than enough.

Well, but this custom behaviour is the foundation of Og, no?  :)


class MyModel
   attr_accessor :oid, UUID

would work, because :oid is the standard primary key.

But anyway, that issue is pretty much not major. :)  This is just
a 'goal' for me to make Og useable without having to look up any
API and make similar operations look similar.

a)  how do I define a different primary key?
b)  attr_accessor :foo, String, :primary_key => true
a)  how about UUID primary keys?
b)  oh yeah, for that it's different, you need to include...

I'd also need to expand my 'by what methods you can enchant an
Og model' by the option "Special Primary Key modifer modules".

>> Ah, and I absolutely hate the to 22 encoder, it doesn't preserve
>> the orderability of the time-uuids.  ;/  But I guess that's the
>> price you pay for not using more bytes..
> you have a point here, but I *really* love the uuids. If someone can  
> suggest a better encoder  I would like to hear about it.

Actually I think the encoder is just fine, it's just that it's initialized
a little 'off'.

@@chars64=['-'] + ('0'..'9').to_a + ('A'..'Z').to_a + ['_']  
+ ('a'..'z').to_a

instead of the stock one could do the trick.

(Right now I'm not using timestamped ones, only hashed, so I kinda
avoided that issue..)
And of course I'm not sure how backwards compatible that change would
be.  From the DB side this would be ok, since none of the primary
keys actually change....  can it happen that new keys conflict with
old ones due to the encoding?  So maybe this change should go in
while 0.50 is not yet out so it doesn't break afterwards.

I hope you could cope with this?  Your apps are all running on that,
so you'd always need to keep the old one...  Or some kind of 're-encoder'
for old uuids..

> -g (enjoying his last few 'free' days ;-))

Enjoy! :)


Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

More information about the Nitro-general mailing list