Elver Loho wrote: > And what's with demanding that every table have an "id" field? I want
It isn't needed. You can have any other name as a primary key. > to use SQLObject with old, legacy databases. Like right now I'm > working with a webstore database where the Transactions table's > primary key is an 11-letter varchar named "code". I don't see *any* > point to enforcing that it be named "id" and it be of type integer. Of you course you read the docs and saw that it can be of type str or int and that it can have any name. You just have to tell that through the sqlmeta class. > With PyGTK and SQLObject I recently built a translation GUI for our > webstore. Hacking around SQLObject's limitations was a real pain in > the butt. Among other things I had to add an 'id' field to an existing > database just because SQLObject can't live without it. If you want it to generate the keys for you then that's one thing that you have to live with. If you're generating the key yourself then you aren't restricted by that. > Sure, SQLObject is mondo awesome when you're building a new system > from scratch. However, it plain sucks when you try to use it with > existing databases. This situation itself meta-sucks, because there > really aren't any better alternatives out there. Have you considered SQL Alchemy? -- Jorge Godoy <[EMAIL PROTECTED]> "Quidquid latine dictum sit, altum sonatur." - Qualquer coisa dita em latim soa profundo. - Anything said in Latin sounds smart. ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ sqlobject-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
