--- Ben Staude <[EMAIL PROTECTED]> 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/[email protected]/ > ____________________________________________________________________________________ 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 _______________________________________________ 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/[email protected]/
