Thread: [SQLObject] _idName not working for me.
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Ben S. <sch...@pr...> - 2005-02-08 15:14:09
|
I'm running Python 2.4 with SQLObject 0.6.1, psycopg-1.1.18 and Postgres 8.0 under Windows Server 2003. Loading an existing class definition from the database (like the Person example) works just fine until I wanna use a different name for my id. For example: With the following table structure: CREATE TABLE entity ( entity_id serial NOT NULL, url varchar, CONSTRAINT entity_pkey PRIMARY KEY (entity_id) ) WITH OIDS; ALTER TABLE entity OWNER TO postgres; I get the following result: >>> class Entity(SQLObject): ... _idName='entityId' ... _fromDatabase = True ... 1/Pool : ACQUIRE pool=[] 1/QueryAll: SELECT pg_catalog.pg_get_constraintdef(oid) as condef FROM pg_catalog.pg_constraint r WHERE r.conrelid = 'entity'::regclass AND r.contype = 'f' 1/Pool : RELEASE (implicit, autocommit=True) pool=[] 1/COMMIT : auto 1/Pool : ACQUIRE pool=[] 1/QueryAll: SELECT pg_index.indisprimary, pg_catalog.pg_get_indexdef(pg_index.indexrelid) FROM pg_catalog.pg_class c, pg_catalog.pg_class c2, pg_catalog.pg_index AS pg_index WHERE c.relname = 'entity' AND c.oid = pg_index.indrelid AND pg_index.indexrelid = c2.oid AND pg_index.indisprimary 1/Pool : RELEASE (implicit, autocommit=True) pool=[] 1/COMMIT : auto 1/Pool : ACQUIRE pool=[] 1/QueryAll: SELECT a.attname, pg_catalog.format_type(a.atttypid, a.atttypmod), a.attnotnull, (SELECT substring(d.adsrc for 128) FROM pg_catalog.pg_attrdef d WHERE d.adrelid=a.attrelid AND d.adnum = a.attnum) FROM pg_catalog.pg_attribute a WHERE a.attrelid ='entity'::regclass AND a.attnum > 0 AND NOT a.attisdropped ORDER BY a.attnum 1/Pool : RELEASE (implicit, autocommit=True) pool=[] 1/COMMIT : auto Traceback (most recent call last): File "<interactive input>", line 1, in ? File "C:\Python24\Lib\site-packages\sqlobject\main.py", line 179, in __new__ newClass.addColumnsFromDatabase() File "C:\Python24\Lib\site-packages\sqlobject\main.py", line 505, in addColumnsFromDatabase for columnDef in conn.columnsFromSchema(cls._table, cls): File "C:\Python24\Lib\site-packages\sqlobject\postgres\pgconnection.py", line 187, in columnsFromSchema colClass, kw = self.guessClass(t) File "C:\Python24\Lib\site-packages\sqlobject\postgres\pgconnection.py", line 201, in guessClass return col.StringCol, {'length': int(t[t.index('(')+1:-1])} ValueError: substring not found >>> I've also tried _idName = 'entity_id' not being certain if the name mangling occurs here or not.and got the exact same results. Otherwise - interesting product and I'm really excited about using it for me present development. But I gotta be able to suck in my existing database schema rather than define it from python. thanx & later, Ben Scherrey |
From: Oleg B. <ph...@ma...> - 2005-02-08 15:40:49
|
On Tue, Feb 08, 2005 at 10:14:05AM -0500, Ben Scherrey wrote: > CREATE TABLE entity > ( > entity_id serial NOT NULL, > url varchar, > CONSTRAINT entity_pkey PRIMARY KEY (entity_id) > ) > Traceback (most recent call last): > File "<interactive input>", line 1, in ? > File "C:\Python24\Lib\site-packages\sqlobject\main.py", line 179, in > __new__ > newClass.addColumnsFromDatabase() > File "C:\Python24\Lib\site-packages\sqlobject\main.py", line 505, in > addColumnsFromDatabase > for columnDef in conn.columnsFromSchema(cls._table, cls): > File > "C:\Python24\Lib\site-packages\sqlobject\postgres\pgconnection.py", line > 187, in columnsFromSchema > colClass, kw = self.guessClass(t) > File > "C:\Python24\Lib\site-packages\sqlobject\postgres\pgconnection.py", line > 201, in guessClass > return col.StringCol, {'length': int(t[t.index('(')+1:-1])} > ValueError: substring not found It seems the problem is not in entity_id, but in guessing type for the "url" column... Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ben S. <sch...@pr...> - 2005-02-08 15:50:30
|
Doh! You're right. Changing the specification of url to varchar(100) resolves the error. Is there something about SqlObject that requires a size specification? I'd hate to have to go into all my databases and define column sizes for every element in the table structures. Most all of my data is specified as straight varchar. thanx & later, Ben Scherrey Oleg Broytmann wrote: >On Tue, Feb 08, 2005 at 10:14:05AM -0500, Ben Scherrey wrote: > > >>CREATE TABLE entity >>( >> entity_id serial NOT NULL, >> url varchar, >> CONSTRAINT entity_pkey PRIMARY KEY (entity_id) >>) >> >> ><snip> > It seems the problem is not in entity_id, but in guessing type for >the "url" column... > >Oleg. > > |
From: Oleg B. <ph...@ph...> - 2005-02-08 16:12:31
|
On Tue, Feb 08, 2005 at 10:50:24AM -0500, Ben Scherrey wrote: > Doh! You're right. Changing the specification of url to varchar(100) > resolves the error. Is there something about SqlObject that requires a > size specification? Look carefully to the traceback you have sent. See the guessing code in sqlobject/postgres/pgconnection.py. Patch it. Patches will be gladly accepted, if they can pass the test suite. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ian B. <ia...@co...> - 2005-02-08 16:49:17
|
Ben Scherrey wrote: > Doh! You're right. Changing the specification of url to varchar(100) > resolves the error. Is there something about SqlObject that requires a > size specification? I'd hate to have to go into all my databases and > define column sizes for every element in the table structures. Most all > of my data is specified as straight varchar. I think it's a very thing, or maybe just a flaw in the method -- it looks for types of "TEXT" but I believe Postgres prefers the name "CHARACTER VARYING" and will return that type. Anyway, I added it to the unit tests, and a fix should come along later. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Ben S. <sch...@pr...> - 2005-02-08 21:53:07
|
Ok, here's a hack fix I threw in that works for both cases of VARCHAR and VARCHAR(n): pgconnection.py:197 def guessClass(self, t): if t.count('int'): return col.IntCol, {} elif t.count('varying'): if '(' in t: return col.StringCol, {'length': int(t[t.index('(')+1:-1])} return col.StringCol, {} ...continues Now that it works I've discovered the frustration that I can only run a piece of SQLObject using code once in a session of PythonWin. After that, all subsequent executions will return the following: Traceback (most recent call last): File "C:\Python24\Lib\site-packages\pythonwin\pywin\framework\scriptutils.py", line 310, in RunScript exec codeObject in __main__.__dict__ File "E:\develop\crm\sqlobjecttest.py", line 6, in ? class Entity(SQLObject): File "C:\Python24\Lib\site-packages\sqlobject\main.py", line 201, in __new__ classregistry.registry(newClass._registry).addClass(newClass) File "C:\Python24\Lib\site-packages\sqlobject\classregistry.py", line 71, in addClass raise ValueError( AttributeError: 'module' object has no attribute '__file__' I assume this is some module/global reload issue but it sure makes my debugging time consuming cause I have to shutdown PythonWin and reload all my environment again each execution session. No forgiveness here. Any ideas on how to address this? thanx & later, Ben Scherrey Ian Bicking wrote: > Ben Scherrey wrote: > >> Doh! You're right. Changing the specification of url to varchar(100) >> resolves the error. Is there something about SqlObject that requires >> a size specification? I'd hate to have to go into all my databases >> and define column sizes for every element in the table structures. >> Most all of my data is specified as straight varchar. > > > I think it's a very thing, or maybe just a flaw in the method -- it > looks for types of "TEXT" but I believe Postgres prefers the name > "CHARACTER VARYING" and will return that type. > > Anyway, I added it to the unit tests, and a fix should come along later. > |
From: Oleg B. <ph...@ph...> - 2005-02-10 17:40:53
|
BTW, will you commited the fix? On Tue, Feb 08, 2005 at 04:53:03PM -0500, Ben Scherrey wrote: > Ok, here's a hack fix I threw in that works for both cases of VARCHAR > and VARCHAR(n): > pgconnection.py:197 > def guessClass(self, t): > if t.count('int'): > return col.IntCol, {} > elif t.count('varying'): > if '(' in t: > return col.StringCol, {'length': int(t[t.index('(')+1:-1])} > return col.StringCol, {} Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ian B. <ia...@co...> - 2005-02-10 17:46:44
|
Oleg Broytmann wrote: > BTW, will you commited the fix? I actually haven't been able to see the error yet. Maybe it's a PG 7.2 thing? I can't figure it out; if you can get the test to fail (test_auto) and then pass with this fix, I'd feel better that we were doing a sufficient test. > On Tue, Feb 08, 2005 at 04:53:03PM -0500, Ben Scherrey wrote: > >>Ok, here's a hack fix I threw in that works for both cases of VARCHAR >>and VARCHAR(n): >>pgconnection.py:197 >> def guessClass(self, t): >> if t.count('int'): >> return col.IntCol, {} >> elif t.count('varying'): >> if '(' in t: >> return col.StringCol, {'length': int(t[t.index('(')+1:-1])} >> return col.StringCol, {} > > > Oleg. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Oleg B. <ph...@ph...> - 2005-02-10 17:52:53
|
On Thu, Feb 10, 2005 at 11:46:34AM -0600, Ian Bicking wrote: > Oleg Broytmann wrote: > >BTW, will you commited the fix? > > I actually haven't been able to see the error yet. Maybe it's a PG 7.2 > thing? Ben have said he runs Pg 8.0. > I can't figure it out; if you can get the test to fail > (test_auto) and then pass with this fix, I'd feel better that we were > doing a sufficient test. I'll try it on Pg 7.2. > >On Tue, Feb 08, 2005 at 04:53:03PM -0500, Ben Scherrey wrote: > > > >>Ok, here's a hack fix I threw in that works for both cases of VARCHAR > >>and VARCHAR(n): > >>pgconnection.py:197 > >> def guessClass(self, t): > >> if t.count('int'): > >> return col.IntCol, {} > >> elif t.count('varying'): > >> if '(' in t: > >> return col.StringCol, {'length': int(t[t.index('(')+1:-1])} > >> return col.StringCol, {} Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ian B. <ia...@co...> - 2005-02-10 18:03:18
|
Oleg Broytmann wrote: > On Thu, Feb 10, 2005 at 11:46:34AM -0600, Ian Bicking wrote: > >>Oleg Broytmann wrote: >> >>>BTW, will you commited the fix? >> >>I actually haven't been able to see the error yet. Maybe it's a PG 7.2 >>thing? > > > Ben have said he runs Pg 8.0. I'm testing on 7.4, so maybe it's an 8.0 thing. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Oleg B. <ph...@ph...> - 2005-02-10 18:19:10
|
On Thu, Feb 10, 2005 at 12:03:07PM -0600, Ian Bicking wrote: > > Ben have said he runs Pg 8.0. > > I'm testing on 7.4, so maybe it's an 8.0 thing. Ben, are you listening? Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ben S. <sch...@pr...> - 2005-02-10 18:42:02
|
Yes Sir! :) You're correct I am running 8.0 and don't have an earlier system to test against. I'm reviewing the inheritence tree version now to see if that's gonna work for me. The critical issue is being able to have the class definitions generate from the database structure as much as possible. Is there anything else you need from me at this time? BTW - I really do appreciate the excellent responsiveness on this list. From everyone, but especially Oleg & Ian. You give your project a lot of credibility as a result, and I'm more inclined to stick with SQLObject than go on my own or use something else as a result. My one issue is that its under a LGPL license rather than something more akin to BSD or Python license. Has that ever been considered/discussed? Just curious - not interested in a license debate. thanx & later, Ben Scherrey Oleg Broytmann wrote: >On Thu, Feb 10, 2005 at 12:03:07PM -0600, Ian Bicking wrote: > > >>> Ben have said he runs Pg 8.0. >>> >>> >>I'm testing on 7.4, so maybe it's an 8.0 thing. >> >> > > Ben, are you listening? > >Oleg. > > |
From: Oleg B. <ph...@ph...> - 2005-02-10 18:52:53
|
On Thu, Feb 10, 2005 at 01:41:46PM -0500, Ben Scherrey wrote: > Yes Sir! :) You're correct I am running 8.0 and don't have an > earlier system to test against. I'm reviewing the inheritence tree > version now to see if that's gonna work for me. The critical issue is > being able to have the class definitions generate from the database > structure as much as possible. > > Is there anything else you need from me at this time? The small patch you have posted - does it help? Haven't it caused any other problems? If the answers are "yes" and "no" - can you write a small test program for the problem the patch solves? The program that fails without your patch and works with it. I'll test it on Pg 7.2 and convert to the current test suite farmework. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ben S. <sch...@pr...> - 2005-02-10 18:56:37
|
Oh yes - it fixed the problem. I'll have to look at how your test suite is setup and see if I can't put together something that reproduces it. Dunno if versions of Postgres prior to 8 would have the issue or not. best regards, Ben Scherrey Oleg Broytmann wrote: >On Thu, Feb 10, 2005 at 01:41:46PM -0500, Ben Scherrey wrote: > > >> Yes Sir! :) You're correct I am running 8.0 and don't have an >>earlier system to test against. I'm reviewing the inheritence tree >>version now to see if that's gonna work for me. The critical issue is >>being able to have the class definitions generate from the database >>structure as much as possible. >> >> Is there anything else you need from me at this time? >> >> > > The small patch you have posted - does it help? Haven't it caused any >other problems? If the answers are "yes" and "no" - can you write a small >test program for the problem the patch solves? The program that fails >without your patch and works with it. I'll test it on Pg 7.2 and convert >to the current test suite farmework. > >Oleg. > > |
From: Oleg B. <ph...@ph...> - 2005-02-10 19:25:10
|
On Thu, Feb 10, 2005 at 01:56:30PM -0500, Ben Scherrey wrote: > I'll have to look at how your test suite > is setup and see if I can't put together something that reproduces it. For the current tests you need the py.test module and sqlite. Sqlite is a must even if you run the tests in Postgres. If you don't want to download and install them - just roll any python script that creates tables and does a test - I'll convert it myself. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |