Thread: Re: Globally Unique IDs, was Re: [SQLObject] Re: SQLObject
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Edmund L. <el...@in...> - 2003-04-11 17:38:04
|
Ian Bicking <ia...@co...> wrote: >> > Another thought in this context is that PostgreSQL already inserts an >> > object id column for every table. But maybe it's not a good idea to >> > use since other dbms don't have equivalents... This is a really bad idea. OIDs are not preserved across db dumps, and are optional in PG 7.3 and above, I think. ...Edmund. |
From: Edmund L. <el...@in...> - 2003-04-11 17:55:35
|
On 04/11/2003 01:47:59 PM Bud P.Bruegger wrote: >But what do you think of Globally Unique IDs? Seems unavoidable in certain situations--e.g., implementing an access control mechanism where you want to grant/revoke rights to all sorts of data scattered across all sorts of tables in a consistent way. I've had to do this myself, and I use triggers and rules to generate/delete the global IDs. I've yet to see a need to have global IDs in any other situation though. Use of global IDs seems to arise mostly when one tries to force an RDBMS to behave like an object store. ...Edmund. |
From: Luke O. <lu...@me...> - 2003-04-11 18:15:21
|
I second Edmund's comments: GlobalIDs have a few specific purposes (which I personally try to avoid :)), but in the discussion of SQLObject being specially aware / making internal use of them, I'm opposed. - Luke Quoting Edmund Lian <el...@in...>: > > On 04/11/2003 01:47:59 PM Bud P.Bruegger wrote: > > >But what do you think of Globally Unique IDs? > > Seems unavoidable in certain situations--e.g., > implementing an access > control mechanism where you want to grant/revoke rights > to all sorts of > data scattered across all sorts of tables in a consistent > way. I've had to > do this myself, and I use triggers and rules to > generate/delete the global > IDs. > > I've yet to see a need to have global IDs in any other > situation though. > Use of global IDs seems to arise mostly when one tries to > force an RDBMS to > behave like an object store. > > ...Edmund. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of > TotalView, The debugger > for complex code. Debugging C/C++ programs can leave you > feeling lost and > disoriented. TotalView can help you find your way. > Available on major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > sqlobject-discuss mailing list > sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss > -- Many people are hamstrung by things like affection for fellow employees, honesty, desire to appear to be a "nice person," and other crippling limitations not suffered by the truly powerful and successful. |
From: Bud P. B. <bu...@si...> - 2003-04-11 17:48:55
|
On Fri, 11 Apr 2003 13:37:49 -0400 "Edmund Lian" <el...@in...> wrote: > >> > Another thought in this context is that PostgreSQL already inserts an > >> > object id column for every table. But maybe it's not a good idea to > >> > use since other dbms don't have equivalents... > > This is a really bad idea. OIDs are not preserved across db dumps, and are > optional in PG 7.3 and above, I think. > > ...Edmund. Edmund, point taken. I felt it was too implementation dependent myself when I thought of it. But what do you think of Globally Unique IDs? --b |