On Thu, Feb 16, 2006, BJörn Lindqvist wrote: >http://webwareforpython.org/archives/message/20050602.140855.1524ff2b.en.html#sqlobject-discuss >> > But it would be nice if someone extends SQLObject in this aspect... I >> > think it is a hard problem though because SQLObject internally uses a >> > hidden "id" field as every tables primary key. >> >> An ORM works by mapping a row onto an object using a key function. In >> SQLObject, this must be a single immutable field declared to be the >> primary key. By default, the name of this field is 'id' and it's an >> auto_incrementing integer. You can change the name of the column and >> as of 0.6.1 (or 0.7? I forget) you're not restricted to integer >> primary keys. SQLObject can perform queries on these databases using >> the connection.* methods, but it cannot map them onto objects. > >I didn't know about that. In the docs I read that the PK must be >immutable, is that requirement still there? If so, then I don't think >it makes much sense to use another attribute than the hidden 'id' as >the PK. > >> If you can't change your tables, you might want to look at SQLAlchemy, >> which does have composite key support but does not have composite >> foreign key support. In practice this means that you have to tweak > >Are you implying that it is wrong to use composite primary keys? It is >understandable that SQLObject doesn't have support for them because >not every database even have composite primary keys and they are >probably a PITA to implement. My data model looks like this:
I'm in the process of migrating an accounting system I wrote years ago that's based on the Unify RDBMS where all document primary keys consist of a two character prefix and an integer sequence number (think paper invoice pads). The conversion is to use the standard sqlobject default primary key, with a unique index built on the two fields in the record (Unify has a long integer internal record pointer that can be used for the id field -- which solves a problem in which Unify allowed related records to exist without a primary key). The more I think about this, I think this may actually simplify some things since there are processes in the posting process where the prefix and sequence change (e.g. an order is processed to become an invoice). In these situations, one can change the prefix/sequence in the master and all its children without having to go through the create new record with new key, copying all attributes except for the key, and doing the same for all the children. One of the factors that's making my software rewrite go slowly is that I'm having to rethink things I did twenty years ago on a system where all programming had to be done in C, and there weren't as many tools available as there are today. ... Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 ``People from East Germany have found the West so confusing. It's so much easier when you have only one party.'' -- Linus Torvalde, Linux Expo Canada when asked about confusion over many Linux distributions. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ sqlobject-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
