[Dbix-class] (OT) Do you use UUIDs?

John Napiorkowski jjn1056 at yahoo.com
Tue Jul 3 14:17:52 GMT 2007


--- Ben Staude <sben1783 at yahoo.de> wrote:

> Am Montag 02 Juli 2007 15:33 schrieb John
> Napiorkowski:
> 
> [ quote of Chris H. Lacos message ]
> 
> > I also like to use uuids as PK as well, however
> when I
> > am using them as PK's I prefer to use a custom
> domain
> > and type in postgres to create them rather than
> use
> > the DBIC plugin.  That way if my admins need to
> access
> > the database directly and make changes (like add
> rows,
> > etc.) or if I need to have the DB used by
> applications
> > not using DBIC I don't need to worry that the PK's
> > will get messed up.
> 
> Thank you very much for your answers up to now,
> Christopher and John! They 
> make me a lot more confident that uuid is what I
> want. But the statement 
> about direct access to the databases bypassing dbic
> makes something ring in 
> my head... As far as I know, sqlite doesn't support
> uuids by itself, so I 
> would have to rely on dbic resp. Data::UUID.
> Does it, as a not-so-easy-bypassable alternative,
> make any sense to use some 
> sort of "quasi-uuid" that is implemented as an
> INSERT trigger? Something 
> like "DATETIME + RANDOM" or so? My keys don't
> necessarily need to be 
> *universally* unique, but only for my specific
> application where it's 
> unlikely that two instances are run at the very same
> time.
> 
> You talk about "custom domain and type in postgres",
> which sounds a bit like 
> your own "uuid"-implementation, but I don't really
> get the idea how you 
> actually do it.

If you are building your DB for use exclusively in
DBIC then there is no worries, just use the mentioned
CPAN module since it works well and does what you need
with minimum fuss.  Creating a custom domain in
Postgresql is more work and has the downside of
pushing the calculations down to the DB layer and also
can complicate clustering a bit since you have to take
care to make sure replication listeners don't make
their own PKs (which is part of the point really).

I only do this because I have applications that run
under DBIC as well as other tools and I want to make
sure my database plays nicely with others.

The way I do this is to create a procedure in
Postgresql using perl (via PL/Perl) to generate a UUID
and then create a custom domain with that procedure as
it's default value.

I guess Postgresql 8.3 is going to have native UUID
support, so should make that easier.  I'll have to
assume that the clustering tools will make supporting
that just as easy as supporting serials.




> 
> > I do this when I get to use Postgresql.  When I
> have
> > to use Mysql I just go with oldschool serial PKs.
> >
> > --john
> 
> Thanks a lot - Ben
> 
> _______________________________________________
> List:
>
http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
> Wiki: http://dbix-class.shadowcatsystems.co.uk/
> IRC: irc.perl.org#dbix-class
> SVN:
>
http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
> Searchable Archive:
>
http://www.mail-archive.com/dbix-class@lists.rawmode.org/
> 



       
____________________________________________________________________________________
Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow  



More information about the Dbix-class mailing list