Thread: [SQLObject] ANN: SQLObject 0.3
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Ian B. <ia...@co...> - 2003-04-08 04:28:02
|
SQLObject 0.3 has been release: http://sqlobject.org Changes ------- * Automatic table creation based off class. * Create classes from database. * Dynamically add and remove columns to live classes and databases. * anydbm-based backend (queryable database without SQL). * Better caching. * Some bugs fixed. What is it? ----------- SQLObject is an object-relational mapper. It allows you to translate RDBMS table rows into Python objects, and manipulate those objects to transparently manipulate the database. SQLObject emphasizes convenience. It's easy to learn and easy to use, and doesn't require too much typing or use of any tools outside of your editor and your Python source. -- Ian Bicking ia...@co... http://colorstudy.com 4869 N. Talman Ave., Chicago, IL 60625 / 773-275-7241 "There is no flag large enough to cover the shame of killing innocent people" -- Howard Zinn |
From: Bud P. B. <bu...@si...> - 2003-04-09 07:53:04
|
Hi Ian, I'll probably try to clean up the example and send it (looking at the tests and the code...). Also, I was looking through the doc of automatic schema generation and have some questions (that I hope are productive): * createTable(ifNotExists=True): I understand that the default (False) means that tables are created in any case, even if they exist already. Wouldn't it be a better default to create them only if they don't exist already? (Does it raise an exception if already existing tables are re-created or does it simply drop the old ones? -- maybe you could add that to the doc). My rational for asking for this default is that it seems safer and the option could possibly be called "force" instead of ifNotExists--that seems closer to what I would expect (at least in a Unix environment). * dropTable(ifExists=..): is this really necessary? What happens if it does not exist (nothing or exception)? Maybe there is something I don't understand, but I would be happy that after calling dropTable, the table is gone (or else, an exception is raised) no matter what the state was before. (I try to avoid methods with pre-conditions as much as ever possible) * dropTable(dropJoinTables=...): I am wondering whether it makes sense to keep joinTables around since really they make reference to rows in the table and leaving them around leads to dangling references. I noted that the SQL you create for relations does not seem to define foreign keys (at least in an example given in the documentation of an earlier version). But if you had the DBMS take care of these, it would probably even complain to leave the joinTable while removing the other table... hope this is helpful --b On 08 Apr 2003 12:30:30 -0500 Ian Bicking <ia...@co...> wrote: > Damn... I forgot to update the example, it's all broken now. > tests/test.py might be a better example for now (even if not as > compelling) > > On Tue, 2003-04-08 at 12:24, Bud P.Bruegger wrote: > > Ian, > > > > I was excited to see the new release. I just encountered a problem > > when running the people.py example. Gotta run to get my daughter--so > > I thought I'll write this message anyways before I can look into it in > > detail. > > > > I'm running the example with PostgreSQL. I attach the diff that makes > > this somewhat easier (a configuration variable controls which dbms is > > used). > > > > I'm using Python 2.2.1 on Linux. > > > > This is the output to calling > > > > ./people.py create > > > > > > Accessing with user bud and password > > Traceback (most recent call last): > > File "./people.py", line 99, in ? > > table.createTable(ifExists=True) > > TypeError: createTable() got an unexpected keyword argument 'ifExists' > > > > > > Will look at it in more detail tomorrow unless you already solved the > > problem. > > > > cheers > > --bud > > > > > > > > > > On 07 Apr 2003 23:28:52 -0500 > > Ian Bicking <ia...@co...> wrote: > > > > > SQLObject 0.3 has been release: > > > http://sqlobject.org > > /----------------------------------------------------------------- | Bud P. Bruegger, Ph.D. | Sistema (www.sistema.it) | Via U. Bassi, 54 | 58100 Grosseto, Italy | +39-0564-411682 (voice and fax) \----------------------------------------------------------------- |
From: Ian B. <ia...@co...> - 2003-04-10 06:03:14
|
On Wed, 2003-04-09 at 02:52, Bud P.Bruegger wrote: > * createTable(ifNotExists=True): > I understand that the default (False) means that tables are created > in any case, even if they exist already. Wouldn't it be a better > default to create them only if they don't exist already? (Does it > raise an exception if already existing tables are re-created or does > it simply drop the old ones? -- maybe you could add that to the > doc). My rational for asking for this default is that it seems > safer and the option could possibly be called "force" instead of > ifNotExists--that seems closer to what I would expect (at least in a > Unix environment). > > * dropTable(ifExists=..): > is this really necessary? What happens if it does not exist > (nothing or exception)? Maybe there is something I don't > understand, but I would be happy that after calling dropTable, the > table is gone (or else, an exception is raised) no matter what the > state was before. (I try to avoid methods with pre-conditions as > much as ever possible) To me these should act something like mkdir and rmdir do in the filesystem, or like the CREATE and DROP commands do in the database. You should *know* that the tables do or do not exist at the time you run these commands, and if things are not as you expect you should get an error (actually generated by the database). In particular for testing or example situations, where you expect for junk to have been left around, being tolerant is well and good. But by default I don't believe they should be tolerant. > * dropTable(dropJoinTables=...): > I am wondering whether it makes sense to keep joinTables around > since really they make reference to rows in the table and leaving > them around leads to dangling references. I noted that the SQL you > create for relations does not seem to define foreign keys (at least > in an example given in the documentation of an earlier version). > But if you had the DBMS take care of these, it would probably even > complain to leave the joinTable while removing the other table... Yes, I just left that option in for no particular reason. There's probably not a good reason why you'd drop the join but not the table. Right now the join table is made arbitrarily by one of the SQLObject classes (whichever one comes alphabetically first, I think), and dropped along with that same table. Really I suppose it should be created whenever the second table is created, and dropped with the first table is dropped. Ian |
From: Bud P. B. <bu...@si...> - 2003-04-09 16:50:08
Attachments:
budPeople.py
|
Ian, I slighly modified person.py such that it runs "out of the box" (attached). It simply always drops the tables and then recreates them. Also, the connection information is given on the commandline. Example ./person.py pgsql mydb myusername hope this is helpful --b |
From: Ian B. <ia...@co...> - 2003-04-10 06:09:29
|
On Wed, 2003-04-09 at 11:49, Bud P.Bruegger wrote: > I slighly modified person.py such that it runs "out of the box" > (attached). Thanks. I'll have to work this over a little (I'd like it to have the same command-line interface as test.py), but it looks good, and it should replace people.py in CVS soon. Simpler than it was before, to be sure. Ian |