From: Carlos R. <car...@gm...> - 2005-01-18 17:34:50
|
On Tue, 18 Jan 2005 11:10:43 -0600, Ian Bicking <ia...@co...> wrote: > alexander smishlajev wrote: > > ironically, SQLObject serves quite well as ORM, but has very little use > > as ROM: you cannot take a legacy database and use SQLObject to access it > > because of the restrictions SQLObject places on the database schema. > > That hasn't been my experience, but most of the databases I've been > accessing follow reasonable standards and aren't too terribly large. > The only real sticking point that I can think of is the presence of a > single, immutable primary key. Compound keys would be a useful feature. > Support for tables without primary keys (as SQLObject instances; we > already have limited support for them as joins) and support for mutable > primary keys is unlikely to happen. When I need compound keys, I usually end up resorting to the selectBy() method. Couldn't it be optimized a little bit? A composite key method could be 'registered' in the class declaration, hinting at the need for extra indexes for that columns. The example below may seem a little bit forced, but it shows the basic idea: class Person(SQLObject): firstName = StrCol() lastName = StrCol() byName = CompositeKey('firstName', 'lastName') The CompositeKey function would return a method, searching for the firstName & lastName. The appropriate indexes can also be created automatically. Is it a workable solution? -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: car...@gm... mail: car...@ya... |