From orm-devel@mailman.tux4web.de Tue Jan 7 01:48:51 2003 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Mon, 06 Jan 2003 17:48:51 -0800 Subject: [orm-devel] orm/dbclass.py typo and a question on one2many deletions Message-ID: <3E1A3203.20108@ericwalstad.com> At around line 228 in orm/dbclass.py: def invalidate(self, name): """ Reset the attribite NAME so it will be read from the db next time it's accessed. Only works for Relationships. """ if self._data.has_key(name) and \ isinstance(self.columns[name], relationships.relationship): del self._data[name] seld._data[name] = self.columns[name].column() ---------------^ should be self._data[name] = self.columns[name].column() Also, I'm having some trouble figuring out how to deal with a one2many relationship. I've got: invoices (one) invoice_line_items (many) and I'm trying to delete an invoice_line_item from both the database and the invoice dbclass object. The invoice_line_item is getting deleted from the db, as expected, but not from the invoice.invoice_line_item list: >>> for li in invoice.invoice_line_items: ... print li.oid() ... 29761419 29928975 29928976 >>> invoice.invoice_line_items[0].oid() 29761419 >>> invoice.invoice_line_items[0].delete() ============================================================ DELETE FROM invoice_line_items WHERE oid=29761419 ============================================================ >>> ds.commit() >>> for li in invoice.invoice_line_items: ... print li.oid() ... 29761419 29928975 29928976 >>> I'd like the second loop to result in: 29928975 29928976 so that the .delete()ed invoice_line_item is also deleted from the invoice list. What is the standard procedure for doing such a thing? Thanks! I hope you all had a pleasant holiday season. Best, Eric. PS, here's my dbclass Table definitions: class invoice_line_items(dbclass): columns = { "id" :integer(), "quantity" :varchar(), "description" :varchar(), "unit_price" :varchar(), "item_date" :timestamp(), "invoices_id" :integer()} class invoices(dbclass): columns = { "id" :integer(), "invoice_date" :timestamp(), "date_paid" :timestamp(), "void" :boolean(), "tax_rate" :varchar(), "project_id" :integer(), "remarks" :varchar(), "payment_memo" :text(), "invoice_line_items":one2many(invoice_line_items, "invoices_id")} From orm-devel@mailman.tux4web.de Wed Jan 8 09:38:25 2003 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Wed, 8 Jan 2003 10:38:25 +0100 Subject: [orm-devel] orm/dbclass.py typo and a question on one2many deletions In-Reply-To: <3E1A3203.20108@ericwalstad.com> References: <3E1A3203.20108@ericwalstad.com> Message-ID: <15899.61841.730450.913176@lisa.tux4web.de> > seld._data[name] = self.columns[name].column() >---------------^ >should be self._data[name] = self.columns[name].column() Thank you for this one... >Also, I'm having some trouble figuring out how to deal with a one2many >relationship. I've got: > >>> invoice.invoice_line_items[0].delete() This one should read del invoice.invoice_line_items[0] I have to admin that one2manyList's __delslice__ method was not tested at all and that there was no __delitem__ method. I've added these and did some rudimentary testing. Check out the latest CVS! BTW: I'm going to write the many2manyList __del*__ methods some time soon, they should be available shortly. >Thanks! I hope you all had a pleasant holiday season. Thanks! Best wishes for the new year to everyone on the list!! Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Wed Jan 8 16:05:51 2003 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Wed, 08 Jan 2003 08:05:51 -0800 Subject: [orm-devel] orm/dbclass.py typo and a question on one2many deletions In-Reply-To: <15899.61841.730450.913176@lisa.tux4web.de> References: <3E1A3203.20108@ericwalstad.com> <15899.61841.730450.913176@lisa.tux4web.de> Message-ID: <3E1C4C5F.90708@ericwalstad.com> Hi Diedrich, Diedrich Vorberg wrote: >>Also, I'm having some trouble figuring out how to deal with a one2many >>relationship. I've got: >> >>>>>invoice.invoice_line_items[0].delete() > > > This one should read > > del invoice.invoice_line_items[0] > > I have to admin that one2manyList's __delslice__ method was not > tested at all and that there was no __delitem__ method. I've added > these and did some rudimentary testing. Check out the latest CVS! Cool! I'll check it out now and give the new methods a try. > BTW: I'm going to write the many2manyList __del*__ methods some time > soon, they should be available shortly. Excellent! I'm just getting started on building a gui interface to a many2many relationship. Thanks again for your efforts! Eric. From orm-devel@mailman.tux4web.de Fri Jan 10 23:19:44 2003 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Sat, 11 Jan 2003 00:19:44 +0100 Subject: [orm-devel] orm/dbclass.py typo and a question on one2many deletions In-Reply-To: <3E1C4C5F.90708@ericwalstad.com> References: <3E1A3203.20108@ericwalstad.com> <15899.61841.730450.913176@lisa.tux4web.de> <3E1C4C5F.90708@ericwalstad.com> Message-ID: <15903.21776.715535.252030@lisa.tux4web.de> Hi Ross, >> BTW: I'm going to write the many2manyList __del*__ methods some time >> soon, they should be available shortly. >Excellent! I'm just getting started on building a gui interface to a >many2many relationship. I've writen the many2manyList.__delslice__() method and did a basic sanity test. dbobj.many2manyList.append(new_object) and del dbobj.many2manyList[dbobj.many2manyList(new_object)] should work now. Both lines will effect the data in memory as well as create and execute proper SQL. Please don't hesitate to contact me if there's anything wrong :-) Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Fri Jan 10 23:22:57 2003 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: 11 Jan 2003 00:22:57 +0100 Subject: [orm-devel] What do you think should go into 1.0? Message-ID: <87k7hcmvxq.fsf@lisa.tux4web.de> The subject says it. What are your experiances in terms of stability? Are there any features you keep avoiding because you can't rely on them? Or because they didn't work as you expected? Do you use ORM in a production environment and how is development going? Just a thought... Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Fri Jan 10 23:23:42 2003 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: 11 Jan 2003 00:23:42 +0100 Subject: [orm-devel] Another one: marixTable Message-ID: <87iswwmvwh.fsf@lisa.tux4web.de> Last questions for today, I promise: I think Ross brought up that the identifyers aroung matrixTable are not well chosen. What are your favorite alternatives? linkTable many2manyTable (ugh!) Just a little detail... Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Mon Jan 13 05:58:00 2003 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Sun, 12 Jan 2003 21:58:00 -0800 Subject: [orm-devel] orm/dbclass.py typo and a question on one2many deletions In-Reply-To: <15903.21776.715535.252030@lisa.tux4web.de> References: <3E1A3203.20108@ericwalstad.com> <15899.61841.730450.913176@lisa.tux4web.de> <3E1C4C5F.90708@ericwalstad.com> <15903.21776.715535.252030@lisa.tux4web.de> Message-ID: <3E225568.6080708@ericwalstad.com> Thanks Diedrich!! Diedrich Vorberg wrote: > Hi Ross, > > >>>BTW: I'm going to write the many2manyList __del*__ methods some time >>>soon, they should be available shortly. >> >>Excellent! I'm just getting started on building a gui interface to a >>many2many relationship. > > > I've writen the many2manyList.__delslice__() method and did a basic > sanity test. > > dbobj.many2manyList.append(new_object) > > and > > del dbobj.many2manyList[dbobj.many2manyList(new_object)] > > should work now. Both lines will effect the data in memory as well as > create and execute proper SQL. Please don't hesitate to contact me if > there's anything wrong :-) > > Diedrich From orm-devel@mailman.tux4web.de Mon Jan 13 06:06:01 2003 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Sun, 12 Jan 2003 22:06:01 -0800 Subject: [orm-devel] What do you think should go into 1.0? In-Reply-To: <87k7hcmvxq.fsf@lisa.tux4web.de> References: <87k7hcmvxq.fsf@lisa.tux4web.de> Message-ID: <3E225749.9060305@ericwalstad.com> Diedrich, Diedrich Vorberg wrote: > The subject says it. > > What are your experiances in terms of stability? My experience so far is that your work is very stable. > Are there any > features you keep avoiding because you can't rely on them? Or because > they didn't work as you expected? I'm still unable to use column type 'float' but it is working for me to just use varchar instead. I admit that I haven't tried to understand why it isn't working for me. But, varchar column type does work for me for now, so I'm just going to stick with it until I *have* to learn the details of the float column type. :P > Do you use ORM in a production > environment and how is development going? Sort of. I'm porting a financial tracking application from MS Access 2000 to wxPython. This is my first wxPython app and I thought this would be a good exercise for learning. It is. I like it a lot, especially the cross-platform feature. Orm is fitting in nicely with the app. I like that orm's interface is simple, and intuitive, much like Python itself. Best regards, Eric. From orm-devel@mailman.tux4web.de Mon Jan 13 06:15:51 2003 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Sun, 12 Jan 2003 22:15:51 -0800 Subject: [orm-devel] What do you think should go into 1.0? In-Reply-To: <87k7hcmvxq.fsf@lisa.tux4web.de> References: <87k7hcmvxq.fsf@lisa.tux4web.de> Message-ID: <3E225997.3000306@ericwalstad.com> Diedrich, I forgot to mention that I have a PostgreSQL view with an "interval" data type: View "funding_summary" Column | Type | Modifiers ---------------+-----------------------------+----------- fsid | integer | ... days_remain | interval | Notice that days_remain is of type interval, which when rendered looks like: SELECT days_remain FROM funding_summary LIMIT 1; days_remain ------------- 213 days (1 row) I'm just starting to play around with this view, but I'm assuming that I should have a dbclass definition like this: # Views class funding_summary(dbclass): columns = {"fsid" :integer(), ... "days_remain" :varchar()} That is, that the "interval" type should be a "varchar" orm column. Is it reasonable to request you add an alias for interval types? Thanks, Eric. -- _________________________ Eric Walstad 222 Winfield Street San Francisco, CA 94110 415-643-0812 voice & fax eric@ericwalstad.com _________________________ Diedrich Vorberg wrote: > The subject says it. > > What are your experiances in terms of stability? Are there any > features you keep avoiding because you can't rely on them? Or because > they didn't work as you expected? Do you use ORM in a production > environment and how is development going? > > Just a thought... > > Diedrich > From orm-devel@mailman.tux4web.de Mon Jan 13 06:43:12 2003 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Sun, 12 Jan 2003 22:43:12 -0800 Subject: [orm-devel] No such attribute or function 'oid' In-Reply-To: <3E225997.3000306@ericwalstad.com> References: <87k7hcmvxq.fsf@lisa.tux4web.de> <3E225997.3000306@ericwalstad.com> Message-ID: <3E226000.3080304@ericwalstad.com> Diedrich, I guess that I can't work with PostgreSQL views as orm objects because views don't have oid's(?). It seems orm is reliant on oid (at least for PostgreSQL). It might be nice to be able to specify the primary key in when creating the dbclass subclass and having it us the pk instead of the oid. Just a thought. Best regards, Eric. -- _________________________ Eric Walstad 222 Winfield Street San Francisco, CA 94110 415-643-0812 voice & fax eric@ericwalstad.com _________________________ funds = self.ds.selectByClauses(funding_summary, where="fsid = %d" % self.invoice.id).fetchall() ============================================================ SELECT funding_summary.oid, funding_summary.time_start,funding_summary.name,funding_summary.funding_limit,funding_summary.days_remain,funding_summary.time_end,funding_summary.fsid,funding_summary.amt_remain FROM funding_summary WHERE fsid = 318 ============================================================ Traceback (most recent call last): File "ewwork.py", line 514, in OnLinkToFundingSources funds = self.ds.selectByClauses(funding_summary, where="fsid = %d" % self.invoice.id).fetchall() File "/usr/lib/python2.2/site-packages/orm/datasource.py", line 302, in selectByClauses return self.runSelect(dbclass, query) File "/usr/lib/python2.2/site-packages/orm/adapters/pgsql/datasource.py", line 286, in runSelect return orm.datasource.datasource_base.runSelect(self, dbclass, query) File "/usr/lib/python2.2/site-packages/orm/datasource.py", line 331, in runSelect cursor = self.execute(query) File "/usr/lib/python2.2/site-packages/orm/adapters/pgsql/datasource.py", line 376, in execute cursor.execute(query) psycopg.ProgrammingError: ERROR: No such attribute or function 'oid' Eric Walstad wrote: > Diedrich, > I forgot to mention that I have a PostgreSQL view with an "interval" > data type: > View "funding_summary" > Column | Type | Modifiers > ---------------+-----------------------------+----------- > fsid | integer | > ... > days_remain | interval | > > Notice that days_remain is of type interval, which when rendered looks > like: > SELECT days_remain FROM funding_summary LIMIT 1; > days_remain > ------------- > 213 days > (1 row) > > I'm just starting to play around with this view, but I'm assuming that I > should have a dbclass definition like this: > # Views > class funding_summary(dbclass): > columns = {"fsid" :integer(), > ... > "days_remain" :varchar()} > > That is, that the "interval" type should be a "varchar" orm column. Is > it reasonable to request you add an alias for interval types? > > Thanks, > > Eric. From orm-devel@mailman.tux4web.de Mon Jan 13 13:50:29 2003 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Mon, 13 Jan 2003 14:50:29 +0100 Subject: [orm-devel] No such attribute or function 'oid' In-Reply-To: <3E226000.3080304@ericwalstad.com> References: <87k7hcmvxq.fsf@lisa.tux4web.de> <3E225997.3000306@ericwalstad.com> <3E226000.3080304@ericwalstad.com> Message-ID: <15906.50213.339554.329788@lisa.tux4web.de> Hi Eric, >I guess that I can't work with PostgreSQL views as orm objects because >views don't have oid's(?). It seems orm is reliant on oid (at least for >PostgreSQL). It might be nice to be able to specify the primary key in >when creating the dbclass subclass and having it us the pk instead of >the oid. Just a thought. Yes, the pgsql adapter uses oids. It will add 'oid,' to any SELECT statement it creates. Check out this thread on orm-devel: http://mailman.tux4web.de/pipermail/orm-devel/2002-November/000013.html which contains a patch to adapters.pgsql.datasource that you might find helpfull. Also it might be possible to write the query on the view by hand and use the datasource.runSelect method to execute it. I think that's they way Mike went. The selectResult class does not rely on the oid to be present. Take a look at the patch: do you think it should be included with orm? After Mike found a solution he thought satisfactory the patch didn't make it to the distribution... (Uh.. I don't think it will work nicely, you might need to insert it by hand... sorry about that...) Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Mon Jan 13 14:18:54 2003 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Mon, 13 Jan 2003 15:18:54 +0100 Subject: [orm-devel] What do you think should go into 1.0? In-Reply-To: <3E225997.3000306@ericwalstad.com> References: <87k7hcmvxq.fsf@lisa.tux4web.de> <3E225997.3000306@ericwalstad.com> Message-ID: <15906.51918.473130.231696@lisa.tux4web.de> Hi Eric, >I forgot to mention that I have a PostgreSQL view with an "interval" >data type: I've added a orm.adapters.pgsql.columns.interval and intervalColumn class that will (as psycopg does) convert INTERVAL columns to mx.DateTime.DateTimeDelta instances and back. This should save you some parsing... As usual I've only done a basic sanity test (test_interval.py in the example directory), so use with caution. Do not hesitate to report trouble, of course! The changes are in the CVS. Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Mon Jan 13 14:22:26 2003 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Mon, 13 Jan 2003 15:22:26 +0100 Subject: [orm-devel] What do you think should go into 1.0? In-Reply-To: <3E225749.9060305@ericwalstad.com> References: <87k7hcmvxq.fsf@lisa.tux4web.de> <3E225749.9060305@ericwalstad.com> Message-ID: <15906.52130.511689.483031@lisa.tux4web.de> Hi Eric >> Are there any >> features you keep avoiding because you can't rely on them? Or because > > they didn't work as you expected? >I'm still unable to use column type 'float' but it is working for me to >just use varchar instead. I admit that I haven't tried to understand >why it isn't working for me. But, varchar column type does work for me >for now, so I'm just going to stick with it until I *have* to learn the >details of the float column type. :P Could you be more specifc with this? Could you send me your CREATE statement and the the column class as you'd like it to look. Also please describe with a view words the behaviour you'd expect/like to see and the one you get. I don't even use float columns, I've repleced them with integer(), because I store monetary values (in cents, this was before I wrote the FixedPoint thing). Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Mon Jan 13 14:56:28 2003 From: orm-devel@mailman.tux4web.de (Ross J. Reedstrom) Date: Mon, 13 Jan 2003 08:56:28 -0600 Subject: [orm-devel] No such attribute or function 'oid' In-Reply-To: <15906.50213.339554.329788@lisa.tux4web.de> References: <87k7hcmvxq.fsf@lisa.tux4web.de> <3E225997.3000306@ericwalstad.com> <3E226000.3080304@ericwalstad.com> <15906.50213.339554.329788@lisa.tux4web.de> Message-ID: <20030113145628.GA3889@wallace.ece.rice.edu> On Mon, Jan 13, 2003 at 02:50:29PM +0100, Diedrich Vorberg wrote: > Hi Eric, > > >I guess that I can't work with PostgreSQL views as orm objects because > >views don't have oid's(?). It seems orm is reliant on oid (at least for > >PostgreSQL). It might be nice to be able to specify the primary key in > >when creating the dbclass subclass and having it us the pk instead of > >the oid. Just a thought. > Yes, the pgsql adapter uses oids. It will add 'oid,' to any SELECT > statement it creates. Yeah, this was the one thing I was thinking about bringing up, though it's probably a post-1.0 thing (perhaps not). Oids are now optional on user tables, and are not guaranteed to be unique, anyway, unless you add a unique index on the column. So this problem will start to bite lots of people using regular tables, not just views. My take on it from the orm point of view is to use a PrimaryKey wherever it is defined, and only fall back to oid if there is no such key. This gets complicated when the pkey is compound: more than one column. One answer would be not to support such tables. > Check out this thread on orm-devel: > > http://mailman.tux4web.de/pipermail/orm-devel/2002-November/000013.html > > which contains a patch to adapters.pgsql.datasource that you might > find helpfull. > Take a look at the patch: do you think it should be included with > orm? After Mike found a solution he thought satisfactory the patch > didn't make it to the distribution... To be honest, I didn't dig into this patch, since it seemed to me that the right solution is not to distinguish between table and view, but rather with and without oids. And views are _always_ readonly: you can make them writeable with some extra ON INSERT and ON UPDATE rules. Ross -- Ross Reedstrom, Ph.D. reedstrm@rice.edu Research Scientist phone: 713-348-6166 The Connexions Project http://cnx.rice.edu fax: 713-348-6182 Rice University MS-39 Houston, TX 77005 From orm-devel@mailman.tux4web.de Mon Jan 13 16:44:20 2003 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Mon, 13 Jan 2003 17:44:20 +0100 Subject: [orm-devel] No such attribute or function 'oid' In-Reply-To: <20030113145628.GA3889@wallace.ece.rice.edu> References: <87k7hcmvxq.fsf@lisa.tux4web.de> <3E225997.3000306@ericwalstad.com> <3E226000.3080304@ericwalstad.com> <15906.50213.339554.329788@lisa.tux4web.de> <20030113145628.GA3889@wallace.ece.rice.edu> Message-ID: <15906.60644.340209.391965@lisa.tux4web.de> Hi Ross, >Subject: No such attribute or function 'oid' Did the patch throw this exception? >>... Stuff about gpsql and oids >Yeah, this was the one thing I was thinking about bringing up, though it's >probably a post-1.0 thing (perhaps not). Oids are now optional on >user tables, and are not guaranteed to be unique, anyway, unless you add >a unique index on the column. So this problem will start to bite lots of >people using regular tables, not just views. My take on it from the orm >point of view is to use a PrimaryKey wherever it is defined, and only fall >back to oid if there is no such key. The reason I kept the special treatment of oids is rather 'traditional' than practical: oids and the idea of an "object relational database" inspired orm in the first place. Also the predecessor of orm depended on oids entirely (which turned out to be one of my worst ideas for it, because you couldn't easily backup :-). I wanted to make orm downward-compatible. >This gets complicated when the pkey >is compound: more than one column. One answer would be not to support >such tables. I will have to think about this. It might not be too difficult. Could you send me with a real world example in SQL? The primary key could be a python tuple. >> http://mailman.tux4web.de/pipermail/orm-devel/2002-November/000013.html >> which contains a patch to adapters.pgsql.datasource that you might >To be honest, I didn't dig into this patch, since it seemed to me that >the right solution is not to distinguish between table and view, but >rather with and without oids. Since there is no reason to keep this compatibility I could make a column type oid() which provides the old functionality but is optional for the dbclasses. This way a view would be a regular dbclass with its tablename attribute set to "table0, table1" this should work fine. >And views are _always_ readonly: you can make them writeable with >some extra ON INSERT and ON UPDATE rules. Do you mean they are _not_ always readonly? Should this be treated by orm? This could be done with relative ease: I'm thinking of a childclass of dbclass for views which overloads the insertCommand() method so that it returns an appropriate SQL statement for inserting into a view. Do read/write views make sense at all or should they rather be avoided? Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Mon Jan 13 19:35:32 2003 From: orm-devel@mailman.tux4web.de (Ross J. Reedstrom) Date: Mon, 13 Jan 2003 13:35:32 -0600 Subject: [orm-devel] No such attribute or function 'oid' In-Reply-To: <15906.60644.340209.391965@lisa.tux4web.de> References: <87k7hcmvxq.fsf@lisa.tux4web.de> <3E225997.3000306@ericwalstad.com> <3E226000.3080304@ericwalstad.com> <15906.50213.339554.329788@lisa.tux4web.de> <20030113145628.GA3889@wallace.ece.rice.edu> <15906.60644.340209.391965@lisa.tux4web.de> Message-ID: <20030113193532.GB5670@wallace.ece.rice.edu> On Mon, Jan 13, 2003 at 05:44:20PM +0100, Diedrich Vorberg wrote: > Hi Ross, > > >Subject: No such attribute or function 'oid' > Did the patch throw this exception? Didn't try it. BTW, I wasn't the original poster on this, you know. That was Eric Walstad. > >>... Stuff about gpsql and oids > > The reason I kept the special treatment of oids is rather > 'traditional' than practical: oids and the idea of an "object > relational database" inspired orm in the first place. Also the > predecessor of orm depended on oids entirely (which turned out to be > one of my worst ideas for it, because you couldn't easily backup :-). > I wanted to make orm downward-compatible. Well ,the problem is that right now oids are deprecated, but thier correct replacements are really ready. For example, the wire protocol actually provides the OID of a newly inserted tuple, for free. Getting anything else requires an extra round trip to the DB. This is an extra pain when the primary key is a backend generated serial. > >This gets complicated when the pkey > >is compound: more than one column. One answer would be not to support > >such tables. > I will have to think about this. It might not be too difficult. Could > you send me with a real world example in SQL? The primary key could be > a python tuple. So, probably not a big problem,as you see it. That'd be good. > >> http://mailman.tux4web.de/pipermail/orm-devel/2002-November/000013.html > >> which contains a patch to adapters.pgsql.datasource that you might > >To be honest, I didn't dig into this patch, since it seemed to me that > >the right solution is not to distinguish between table and view, but > >rather with and without oids. > Since there is no reason to keep this compatibility I could make a > column type oid() which provides the old functionality but is optional > for the dbclasses. This way a view would be a regular dbclass with > its tablename attribute set to "table0, table1" this should work fine. Hmm, not sure about the strange tablename your suggesting. Let me lecture a bit on views. >From the client's perspective, a view is merely a readonly table. The details of how it's implemented are that the original query is rewritten to access the actual tables, like so: Given tables: CREATE TABLE people (peid serial NOT NULL PRIMARY KEY, name text); CRATE TABLE people_phone (peid int, phoneid int) CREATE TABLE phone (phoneid serial NOT NULL PRIMARY KEY, number text, type text); CREATE VIEW phonebook AS SELECT name,number,type FROM people p,people_phone pp, phones f WHERE p.phoneid = pp.phoneid AND pp.phoneid = f.phoneid; Now: SELECT * from phonebook order by name,type; will yield something like: name | number | type ----------------+--------------+----- Duck, Donald | 589-555-7825 | home Reedstrom, Ross | 713-555-1234 | cell Reedstrom, Ross | 713-555-1212 | home Reedstrom, Ross | 713-348-6166 | office What really happened is that the query was expanded by the view definition, sort of like a macro. But as far as the client is concerned, that's a real table, except for: > >And views are _always_ readonly: you can make them writeable with > >some extra ON INSERT and ON UPDATE rules. > Do you mean they are _not_ always readonly? Should this be treated by Right, _not_ always. > orm? This could be done with relative ease: I'm thinking of a > childclass of dbclass for views which overloads the insertCommand() > method so that it returns an appropriate SQL statement for inserting > into a view. Do read/write views make sense at all or should they > rather be avoided? In some circumstances, read/write views are the only way to go. I think someone's workng on readonly tables, as well, right now. From orm's point of view, rather than implementing the writing in the middleware, we just need to support tables that throw errors on writing. Or, we could require the coder to specify that this is a readonly table (usual case, a regular view) which would then not need to implement all the write support for the mirror class. What do you think of that? Ross From orm-devel@mailman.tux4web.de Mon Jan 13 19:46:24 2003 From: orm-devel@mailman.tux4web.de (Ross J. Reedstrom) Date: Mon, 13 Jan 2003 13:46:24 -0600 Subject: [orm-devel] No such attribute or function 'oid' In-Reply-To: <20030113193532.GB5670@wallace.ece.rice.edu> References: <87k7hcmvxq.fsf@lisa.tux4web.de> <3E225997.3000306@ericwalstad.com> <3E226000.3080304@ericwalstad.com> <15906.50213.339554.329788@lisa.tux4web.de> <20030113145628.GA3889@wallace.ece.rice.edu> <15906.60644.340209.391965@lisa.tux4web.de> <20030113193532.GB5670@wallace.ece.rice.edu> Message-ID: <20030113194624.GC5670@wallace.ece.rice.edu> On Mon, Jan 13, 2003 at 01:35:32PM -0600, Ross J. Reedstrom wrote: > On Mon, Jan 13, 2003 at 05:44:20PM +0100, Diedrich Vorberg wrote: > > Hi Ross, > > > > >Subject: No such attribute or function 'oid' > > Did the patch throw this exception? > > Didn't try it. BTW, I wasn't the original poster on this, you know. That > was Eric Walstad. > > > >>... Stuff about gpsql and oids > > > > The reason I kept the special treatment of oids is rather > > 'traditional' than practical: oids and the idea of an "object > > relational database" inspired orm in the first place. Also the > > predecessor of orm depended on oids entirely (which turned out to be > > one of my worst ideas for it, because you couldn't easily backup :-). > > I wanted to make orm downward-compatible. > > Well ,the problem is that right now oids are deprecated, but thier correct > replacements are really ready. For example, the wire protocol actually ------------------^not Dang, I'm having trouble with dropped negations. > provides the OID of a newly inserted tuple, for free. Getting anything > else requires an extra round trip to the DB. This is an extra pain when > the primary key is a backend generated serial. Ross From orm-devel@mailman.tux4web.de Tue Jan 14 17:47:39 2003 From: orm-devel@mailman.tux4web.de (Mike Watkins) Date: Tue, 14 Jan 2003 09:47:39 -0800 Subject: [orm-devel] No such attribute or function 'oid' In-Reply-To: <3E226000.3080304@ericwalstad.com> References: <3E225997.3000306@ericwalstad.com> <87k7hcmvxq.fsf@lisa.tux4web.de> <3E225997.3000306@ericwalstad.com> Message-ID: <5.1.0.14.0.20030114094248.02096aa0@mail.mikewatkins.net> Yes, you can... a little trick - add "oid" into your select statement. Its a hidden column in each table. For example the view: create view v_published_docs as select d.oid, d.id, d.references_id, d.title, d.abstract, d.content_type_id, d.lang_id, d.author_id, d.create_date, d.modified_date, d.publish_date, d.expiry_date, d.is_syndicated from document d where references_id is null and d.status = 1 and d.publish_date <= now(); Supports this object: class DocumentList(dbclass): tableName='v_published_docs' columns = { "id" : serial() , # "references_id" : # since it references itself, has to be defined after class is defined, see below "title" : varchar() , "abstract" : text() , "content_type_id" : one2one(ContentType) , "lang_id" : one2one(Lang) , "author_id" : one2one(Person) , "create_date" : timestamp() , "modified_date" : timestamp() , "publish_date" : timestamp() , "expiry_date" : timestamp() , "is_syndicated" : boolean() } At 10:43 PM 1/12/2003 -0800, you wrote: >Diedrich, >I guess that I can't work with PostgreSQL views as orm objects because >views don't have oid's(?). It seems orm is reliant on oid (at least for >PostgreSQL). It might be nice to be able to specify the primary key in >when creating the dbclass subclass and having it us the pk instead of the >oid. Just a thought. > >Best regards, > >Eric. > >-- >_________________________ > >Eric Walstad >222 Winfield Street >San Francisco, CA 94110 >415-643-0812 voice & fax >eric@ericwalstad.com >_________________________ > > > > >funds = self.ds.selectByClauses(funding_summary, where="fsid = %d" % >self.invoice.id).fetchall() > >============================================================ >SELECT funding_summary.oid, >funding_summary.time_start,funding_summary.name,funding_summary.funding_limit,funding_summary.days_remain,funding_summary.time_end,funding_summary.fsid,funding_summary.amt_remain >FROM funding_summary WHERE fsid = 318 >============================================================ >Traceback (most recent call last): > File "ewwork.py", line 514, in OnLinkToFundingSources > funds = self.ds.selectByClauses(funding_summary, where="fsid = %d" % > self.invoice.id).fetchall() > File "/usr/lib/python2.2/site-packages/orm/datasource.py", line 302, in > selectByClauses > return self.runSelect(dbclass, query) > File > "/usr/lib/python2.2/site-packages/orm/adapters/pgsql/datasource.py", line > 286, in runSelect > return orm.datasource.datasource_base.runSelect(self, dbclass, query) > File "/usr/lib/python2.2/site-packages/orm/datasource.py", line 331, in > runSelect > cursor = self.execute(query) > File > "/usr/lib/python2.2/site-packages/orm/adapters/pgsql/datasource.py", line > 376, in execute > cursor.execute(query) >psycopg.ProgrammingError: ERROR: No such attribute or function 'oid' > >Eric Walstad wrote: >>Diedrich, >>I forgot to mention that I have a PostgreSQL view with an "interval" data >>type: >> View "funding_summary" >> Column | Type | Modifiers >>---------------+-----------------------------+----------- >> fsid | integer | >>... >> days_remain | interval | >>Notice that days_remain is of type interval, which when rendered looks like: >>SELECT days_remain FROM funding_summary LIMIT 1; >> days_remain >>------------- >> 213 days >>(1 row) >>I'm just starting to play around with this view, but I'm assuming that I >>should have a dbclass definition like this: >># Views >>class funding_summary(dbclass): >> columns = {"fsid" :integer(), >> ... >> "days_remain" :varchar()} >>That is, that the "interval" type should be a "varchar" orm column. Is >>it reasonable to request you add an alias for interval types? >>Thanks, >>Eric. > >_______________________________________________ >orm-devel mailing list >orm-devel@mailman.tux4web.de >http://mailman.tux4web.de/mailman/listinfo/orm-devel From orm-devel@mailman.tux4web.de Wed Jan 15 05:01:05 2003 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Tue, 14 Jan 2003 21:01:05 -0800 Subject: [orm-devel] No such attribute or function 'oid' In-Reply-To: <5.1.0.14.0.20030114094248.02096aa0@mail.mikewatkins.net> References: <3E225997.3000306@ericwalstad.com> <87k7hcmvxq.fsf@lisa.tux4web.de> <3E225997.3000306@ericwalstad.com> <5.1.0.14.0.20030114094248.02096aa0@mail.mikewatkins.net> Message-ID: <3E24EB11.1080905@ericwalstad.com> Hi Mike, This is an interesting idea. The view I'm working on uses multiple tables, none of which, in this query, will provide a unique oid in the result set. I wonder if PostgreSQL has a function that will give me the equivilent of a SERIAL in the query results(?). I could then add that column to the query and name it oid, perhaps. In the mean time, I've implemented Diedrich's solution of using ds.runSelect(), which is working nicely. Thanks for the lead. Eric. -- _________________________ Eric Walstad 222 Winfield Street San Francisco, CA 94110 415-643-0812 voice & fax eric@ericwalstad.com _________________________ Mike Watkins wrote: > Yes, you can... a little trick - add "oid" into your select statement. > Its a hidden column in each table. > > For example the view: > > create view v_published_docs as > select d.oid, d.id, d.references_id, d.title, d.abstract, > d.content_type_id, d.lang_id, d.author_id, d.create_date, > d.modified_date, > d.publish_date, d.expiry_date, d.is_syndicated from document d > where references_id is null and d.status = 1 and d.publish_date <= now(); > > Supports this object: > > class DocumentList(dbclass): > tableName='v_published_docs' > columns = { > "id" : serial() , > # "references_id" : # since it references itself, has to > be defined after class is defined, see below > "title" : varchar() , > "abstract" : text() , > "content_type_id" : one2one(ContentType) , > "lang_id" : one2one(Lang) , > "author_id" : one2one(Person) , > "create_date" : timestamp() , > "modified_date" : timestamp() , > "publish_date" : timestamp() , > "expiry_date" : timestamp() , > "is_syndicated" : boolean() > } > > > At 10:43 PM 1/12/2003 -0800, you wrote: > >> Diedrich, >> I guess that I can't work with PostgreSQL views as orm objects because >> views don't have oid's(?). It seems orm is reliant on oid (at least >> for PostgreSQL). It might be nice to be able to specify the primary >> key in when creating the dbclass subclass and having it us the pk >> instead of the oid. Just a thought. >> >> Best regards, >> >> Eric. >> >> -- >> _________________________ >> >> Eric Walstad >> 222 Winfield Street >> San Francisco, CA 94110 >> 415-643-0812 voice & fax >> eric@ericwalstad.com >> _________________________ >> >> >> >> >> funds = self.ds.selectByClauses(funding_summary, where="fsid = %d" % >> self.invoice.id).fetchall() >> >> ============================================================ >> SELECT funding_summary.oid, >> funding_summary.time_start,funding_summary.name,funding_summary.funding_limit,funding_summary.days_remain,funding_summary.time_end,funding_summary.fsid,funding_summary.amt_remain >> FROM funding_summary WHERE fsid = 318 >> ============================================================ >> Traceback (most recent call last): >> File "ewwork.py", line 514, in OnLinkToFundingSources >> funds = self.ds.selectByClauses(funding_summary, where="fsid = %d" >> % self.invoice.id).fetchall() >> File "/usr/lib/python2.2/site-packages/orm/datasource.py", line 302, >> in selectByClauses >> return self.runSelect(dbclass, query) >> File >> "/usr/lib/python2.2/site-packages/orm/adapters/pgsql/datasource.py", >> line 286, in runSelect >> return orm.datasource.datasource_base.runSelect(self, dbclass, query) >> File "/usr/lib/python2.2/site-packages/orm/datasource.py", line 331, >> in runSelect >> cursor = self.execute(query) >> File >> "/usr/lib/python2.2/site-packages/orm/adapters/pgsql/datasource.py", >> line 376, in execute >> cursor.execute(query) >> psycopg.ProgrammingError: ERROR: No such attribute or function 'oid' >> >> Eric Walstad wrote: >> >>> Diedrich, >>> I forgot to mention that I have a PostgreSQL view with an "interval" >>> data type: >>> View "funding_summary" >>> Column | Type | Modifiers >>> ---------------+-----------------------------+----------- >>> fsid | integer | >>> ... >>> days_remain | interval | >>> Notice that days_remain is of type interval, which when rendered >>> looks like: >>> SELECT days_remain FROM funding_summary LIMIT 1; >>> days_remain >>> ------------- >>> 213 days >>> (1 row) >>> I'm just starting to play around with this view, but I'm assuming >>> that I should have a dbclass definition like this: >>> # Views >>> class funding_summary(dbclass): >>> columns = {"fsid" :integer(), >>> ... >>> "days_remain" :varchar()} >>> That is, that the "interval" type should be a "varchar" orm column. >>> Is it reasonable to request you add an alias for interval types? >>> Thanks, >>> Eric. From orm-devel@mailman.tux4web.de Thu Jan 16 02:15:19 2003 From: orm-devel@mailman.tux4web.de (Julio Rommi =?iso-8859-15?q?O=F1a=20Miranda?=) Date: Wed, 15 Jan 2003 22:15:19 -0400 Subject: [orm-devel] shh closed Message-ID: <20030116021510.C005BB343@pinky.miranda> Hi Eric, This was a long end year to me. I have no posibility to work in anything but I'm back. I've tried yesterday to connect to the cvs server but it tell me thet the ssh port was closed. Could you open it again? thanks. By the way I had a little change in the Datasource object that would allow to use any driver besides mysql and postgres without modifying the source code. On this direction I woud like to make orm definitions driver independent. I mean no mather if you use mysql or postgres or any other a field definition should no change. This implies to select a group of columns types and simulate them where no available. This should no limit the program to use more than a driver any given moment. So you could have two or more diferent Datasources connected to diferent databases. Ok, this implies other things too. I a object is related to a Datasource what should happen when is associated to another different? How a copy should work? or a migration? Well, just ideas while I begin to finish my work. Regards to all. -- Julio From orm-devel@mailman.tux4web.de Fri Jan 17 00:06:13 2003 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Fri, 17 Jan 2003 01:06:13 +0100 Subject: [orm-devel] shh closed In-Reply-To: <20030116021510.C005BB343@pinky.miranda> References: <20030116021510.C005BB343@pinky.miranda> Message-ID: <15911.18677.67492.82209@lisa.tux4web.de> Hi Julio, nice to hear from you! >I've tried yesterday to connect to the cvs server but it tell me thet the ssh >port was closed. Could you open it again? thanks. This probably was a temporary failure of the whole machine. My c200 keeps failing on my :-( I'm experiancing involuntary reboots all of the time. I'm sorry about this! The machine will be replaced as soon as I have some money. But for not it must do! >By the way I had a little change in the Datasource object that would allow to >use any driver besides mysql and postgres without modifying the source code. What other drivers are there? Is there anything you didn't tell us :-)) >On this direction I woud like to make orm definitions driver independent. I >mean no mather if you use mysql or postgres or any other a field definition >should no change. This implies to select a group of columns types and >simulate them where no available. > >This should no limit the program to use more than a driver any given moment. >So you could have two or more diferent Datasources connected to diferent >databases. Ok. Let me say first that I can see your point here. :-) Now here comes mine: My idea with orm is, that it's as close to the RDBMS as it can. That's why I decided to create a datatype/column class pair for every datatype a specific backend provides. Datatypes that exist in all backends (the basic float, integer and string types etc) are defined in orm.columns and are the same classes for every backend. They also work with every backend right now. There is a specific orm.adapters.*.columns module for each backend which (re-)defines Python classes for each type which is specific to a backend. This way orm can benefit from the specific features of an RDBMS but be minimalist, too. I don't think simulation is wise: think of PostgreSQL's datatypes for IPs and netmasks for instance. In MySQL you'd probably store these as strings. There's nothing wrong with that, people do this. On the other hand PostgreSQL provides a specifc datatype and orm makes use of this, as it should. In Python it will return an object which actually represents an IP as an integer. If a user wants to create a datatype/column pair specifically for MySQL to do the same thing he can. However, I don't think it's wise to do that inside orm: the task is just to special. If we'd emulate every type of every backend that's not supported in another backend we'd add quite some complexity to orm which I'd like to avoid. Also, even if we do, these type do not exist at SQL level so that orm's support is only half of the job anway. Some differences are very subtle: MySQL's NUMERIC type fits into Python's integer type nicely. For PostgreSQL's NUMERIC type I had to write a custom datatype/column pair which uses an external module called Fixedpoint. Fixedpoint does arbitrary precision math, as pgsql does. >Ok, this implies other things too. I a object is related to a Datasource what >should happen when is associated to another different? How a copy should >work? or a migration? For copying and migration you will need two datamodels. This is mostly due to the fact that MySQL and PostgreSQL use different mechanisms to return new AUTO INCREMENT values. Here's an example of converting a domain/ host database from MySQL to PostgreSQL: # my_beans.py from orm.columns import * from orm.adapters.mysql.columns import * class host(dbclass): columns = { "id": autoincrement(), "name": varchar(), "ip": varchar() } class domain(dbclass): columns = { "id": autoincrement(), "name": varchar(), "hosts": one2many(host) } # pg_beans.py from orm.columns import * from orm.adapters.pgsql.columns import * class host(dbclass): columns = { "id": serial(), "name": varchar(), "ip": inet() } class domain(dbclass): columns = { "id": serial(), "name": varchar(), "hosts": one2many(host) } # copy.py import my_beans import pg_beans my_ds = ... pg_ds = ... for domain in my_ds.select(my_beans.domain): new_domain = pg_beans.domain(name=domain.name) pg_ds.insert(new_domain) for host in domain.hosts: new_host = pg_beans.host(name=host.name, ip=host.ip) # the inet class's # convert() takes strings, too # I think... pg_ds.insert(new_host) del new_host # delete the object from memory. This is needed # for some reason I didn't quite get. del new_domain pg_ds.commit() >Well, just ideas while I begin to finish my work. I know that flexibility in terms of db backend would be nice. I haven't considered it with orm to keep things simple. Also keep in mind that orm is intended to coexist with hand-writen SQL. This does not change nicely from one db to another, either. Supporting several backends as JDBC does was not intended, really. If you have any ideas on how to achive it easily I'd be eager to here them. >Regards to all. Best wishes to you! Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Fri Jan 17 03:48:40 2003 From: orm-devel@mailman.tux4web.de (Julio Rommi =?iso-8859-1?q?O=F1a=20Miranda?=) Date: Thu, 16 Jan 2003 23:48:40 -0400 Subject: [orm-devel] shh closed In-Reply-To: <15911.18677.67492.82209@lisa.tux4web.de> References: <20030116021510.C005BB343@pinky.miranda> <15911.18677.67492.82209@lisa.tux4web.de> Message-ID: <20030117034821.F23D4A797@pinky.miranda> Hi Diedritch Yesterday I've missend the mail.... ;-) No problem about the server I will try to connect any time from now. Thanks. > What other drivers are there? Is there anything you didn't tell us :-)) I've mention you that a friend was working in a MS SQL driver, well he has not finnished it rigth but maybe soon. The change is easy any way: changing the if construct in something like: try: modulename = "orm.adapters.%s.datasource" % driver datasource = __import__(modulename,locals(),globals(),['datasource']) except [...]: raise "Driver Not found". on this way any driver put into the adapters directory will be load. > > If you have any ideas on how to achive it easily I'd be eager to here > them. > Hmmm, you are rigth, this should be another layer, just leave orm as is, later another groups of classes should be added that perform this task, abstracting like something of Metabase in PHP. Regards. -- Julio From orm-devel@mailman.tux4web.de Mon Jan 20 21:46:38 2003 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Mon, 20 Jan 2003 13:46:38 -0800 Subject: [orm-devel] No such attribute or function 'oid' In-Reply-To: <20030113194624.GC5670@wallace.ece.rice.edu> References: <87k7hcmvxq.fsf@lisa.tux4web.de> <3E225997.3000306@ericwalstad.com> <3E226000.3080304@ericwalstad.com> <15906.50213.339554.329788@lisa.tux4web.de> <20030113145628.GA3889@wallace.ece.rice.edu> <15906.60644.340209.391965@lisa.tux4web.de> <20030113193532.GB5670@wallace.ece.rice.edu> <20030113194624.GC5670@wallace.ece.rice.edu> Message-ID: <3E2C6E3E.1070600@ericwalstad.com> Hi guys, I'm trying to keep up with you here. I'm no postgresql guru, so let me know if I'm following the ideas regarding ORM and oid's... - It seems that the PostgreSQL folks discourage using oid's for user tables [1], as Ross mentioned. - Orm uses oid's to identify unique records for backwards compatibility reasons. - Ross thinks oid's shouldn't be used for pk's because of the known lack of uniqueness (on large databases and/or large tables, see [1]) but that using a pk will result in an extra call to the database on INSERTs; the extra call retreives the newly inserted pk. - Extra calls to the database are bad, a penalty in time and processor load. - Non-unique oid's are bad as they may result in duplicate records. - If ORM used pk's instead of oid's it should be able to deal with compound/multi-column pk's. Diedrich has ideas for how to elegantly handle the issue of compound/multi-column pk's. A question for Diedrich: Will ORM someday support the use of pk's (instead of|in addition to) oid's? In response to Diedrich's request for an example of compound primary key: "Could you send me with a real world example in SQL?" Here's a simple example that allows me to relate a funding source (Contract, Work Authorization, Purchase Order; represents money against which I can bill my clients) to zero or more invoices (or multiple funding sources to an invoice). It has only two fields and both together define the primary key: CREATE TABLE "invoice_funding" ( "invoice_id" integer NOT NULL, "funding_source_id" integer NOT NULL, Constraint "invoice_funding_pkey" Primary Key ("invoice_id", "funding_source_id") ); FWIW, I'd prefer to have orm use pk's instead of oid's, or to have the option to use pk's instead of oid's. I'm less concerned with extra calls to the database than I am of potentially finding duplicate records in an orm result set. If I've misunderstood something, please let me know. Best regards, Eric. [1] http://www.ca.postgresql.org/users-lounge/docs/7.3/postgres/datatype-oid.html Ross J. Reedstrom wrote: > On Mon, Jan 13, 2003 at 01:35:32PM -0600, Ross J. Reedstrom wrote: > >>On Mon, Jan 13, 2003 at 05:44:20PM +0100, Diedrich Vorberg wrote: >> >>>Hi Ross, >>> >>> >>>>Subject: No such attribute or function 'oid' >>> >>>Did the patch throw this exception? >> >>Didn't try it. BTW, I wasn't the original poster on this, you know. That >>was Eric Walstad. >> >> >>>>>... Stuff about gpsql and oids >>> >>>The reason I kept the special treatment of oids is rather >>>'traditional' than practical: oids and the idea of an "object >>>relational database" inspired orm in the first place. Also the >>>predecessor of orm depended on oids entirely (which turned out to be >>>one of my worst ideas for it, because you couldn't easily backup :-). >>>I wanted to make orm downward-compatible. >> >>Well ,the problem is that right now oids are deprecated, but thier correct >>replacements are really ready. For example, the wire protocol actually > > ------------------^not > Dang, I'm having trouble with dropped negations. > > >>provides the OID of a newly inserted tuple, for free. Getting anything >>else requires an extra round trip to the DB. This is an extra pain when >>the primary key is a backend generated serial. > > > Ross From orm-devel@mailman.tux4web.de Mon Jan 20 23:34:19 2003 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Tue, 21 Jan 2003 00:34:19 +0100 Subject: [orm-devel] No such attribute or function 'oid' In-Reply-To: <3E2C6E3E.1070600@ericwalstad.com> References: <87k7hcmvxq.fsf@lisa.tux4web.de> <3E225997.3000306@ericwalstad.com> <3E226000.3080304@ericwalstad.com> <15906.50213.339554.329788@lisa.tux4web.de> <20030113145628.GA3889@wallace.ece.rice.edu> <15906.60644.340209.391965@lisa.tux4web.de> <20030113193532.GB5670@wallace.ece.rice.edu> <20030113194624.GC5670@wallace.ece.rice.edu> <3E2C6E3E.1070600@ericwalstad.com> Message-ID: <15916.34683.299921.36721@lisa.tux4web.de> Good evening! One thing beforehand: I've got a commission I'm busy working on so I can't concentrate on ORM as I would like. I'm sorry about this! This is going to get better in three or maybe four weeks. Then I have to work on a project that actually involves ORM and I'll be with you some more. For now I can only give short and maybe shallow (not so well though through replies). Sorry... > - Orm uses oid's to identify unique records for backwards >compatibility reasons. Yes+no. What ORM does: to every SELECT query's column list it creates it will prepend "oid,". If a result set contains a column called oid this column will be treated special and sored in an attribute called _oid which is accessible through the oid() method. No datatype/column pair is used for the oid. This inconsistency is due to the ideas I had for ORM and it's predecessor. These oids are not actually used anymore. (I think). They only prevent queries on VIEWS to work :-) The idea I expressed in the last eMail was to create a datatype/ column pair for oids and have them treated just like any other column (they would have to be included in your columns dict). This is a rather substantial modification and I need some time for rather thorough testing. > - Ross thinks oid's shouldn't be used for pk's because of the known >lack of uniqueness (on large databases and/or large tables, see [1]) but >that using a pk will result in an extra call to the database on INSERTs; >the extra call retreives the newly inserted pk. Oids are not used as primary keys unless you specify primaryKey="oid" for that dbclass. The orm.adapters.pgsql.datasource's insert() method SELECTs every serial column after the SQL INSERT command is performed. This does cost extra CPU time, of course. If you want to use oid as your primaryKey fine! The insert() method will also store the cursor's lastoid() in the python representation of the newly inserted object. (This is another place where oids are used: to check whether an object has been inserted, yet. The mysql datasource sets _oid=1 for every dbobj it INSERTed.) > - If ORM used pk's instead of oid's it should be able to deal with >compound/multi-column pk's. Diedrich has ideas for how to elegantly >handle the issue of compound/multi-column pk's. >A question for Diedrich: Will ORM someday support the use of pk's >(instead of|in addition to) oid's? It does now! serial pks are the default. (Err...now I see a problem: they're not only the default: they're the only option). If you want to use oids set the dbclass' primaryKey="oid" and things should work fine. This is not tested very much, I'm afraid, since I'm using SERIAL columns, too. Basically any single column can be a pk. I think this could be a problem: only SERIAL columns will be retrieved from the db after an INSERT. Columns with constrains or defaults will not be updated. I was thinking about introducing a mechanism to cope with this kind of situation. >In response to Diedrich's request for an example of compound primary key: >"Could you send me with a real world example in SQL?" >Here's a simple example that allows me to relate a funding source >(Contract, Work Authorization, Purchase Order; represents money against >which I can bill my clients) to zero or more invoices (or multiple >funding sources to an invoice). It has only two fields and both >together define the primary key: > >CREATE TABLE "invoice_funding" ( > "invoice_id" integer NOT NULL, > "funding_source_id" integer NOT NULL, > Constraint "invoice_funding_pkey" Primary Key ("invoice_id", >"funding_source_id") >); Thanks, I'll look into this as time permits, I promise! Hm... looking at this: isn't this a case for a many2many relation and this is the 'matrixTable'? Perhaps I'm too tired... :-( Anyway in that case the CONSTRAINT doesn't touch ORM. Or does it? Or rather not? Sorry... good night...:-)) Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Tue Jan 21 04:20:41 2003 From: orm-devel@mailman.tux4web.de (Julio Rommi =?iso-8859-1?q?O=F1a=20Miranda?=) Date: Tue, 21 Jan 2003 00:20:41 -0400 Subject: [orm-devel] No such attribute or function 'oid' In-Reply-To: <15916.34683.299921.36721@lisa.tux4web.de> References: <87k7hcmvxq.fsf@lisa.tux4web.de> <3E2C6E3E.1070600@ericwalstad.com> <15916.34683.299921.36721@lisa.tux4web.de> Message-ID: <20030121041953.6660C9B0F@pinky.miranda> El Lun 20 Ene 2003 19:34, escribió: Hi everyone! > > > >CREATE TABLE "invoice_funding" ( > > "invoice_id" integer NOT NULL, > > "funding_source_id" integer NOT NULL, > > Constraint "invoice_funding_pkey" Primary Key ("invoice_id", > >"funding_source_id") > >); Well I think this is a matter of style. In any case a would prefer to use a extra field called Invoice_funding_ID and make it PK. And I prefere not to use a real data as a record id but internal selfdefined ones. But in any way I think there should no restriction on the tool so it should be allowed to use the previous construct in ORM. As I recall, I read something like this on some mail but I don't remember when, where a little trick was used to acomplishe this (assigning another string to the oid of the record). If it's posible this could be stablished as an api definition. Regards. -- Julio From orm-devel@mailman.tux4web.de Tue Jan 21 23:57:30 2003 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Wed, 22 Jan 2003 00:57:30 +0100 Subject: [orm-devel] CVS down Message-ID: <15917.56938.329130.244709@lisa.tux4web.de> I've taken CVS pserver down, there's a remote root exploit and I don't want to run any risks. It will be a day or two. Sorry about that! ssh based access should not be affected. Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Wed Jan 22 00:18:55 2003 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Wed, 22 Jan 2003 01:18:55 +0100 Subject: [orm-devel] CVS up Message-ID: <15917.58223.447835.947077@lisa.tux4web.de> This was faster than I thought....