Thread: [SQLObject] SQLObject does not recognize sequence functions if _idName is used
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Luc S. <luc...@ad...> - 2003-07-31 09:46:08
|
Hello, I tried (on PostgreSQL 7.3.3) to use the _fromDatabase=True feature to be able to use my already created tables (manually created, not with SQLObject). SQObject chokes on the parsing of the primary key (which is a serial defined type): ValueError: Unknown SQL builtin type: <type 'instance'> for nextval('public.societe_soc_id_seq'::text) The content of my DB: db => \d societe Table "public.societe" Colonne | Type | Modifications --------------+----------------------+------------------------------------------------------------- soc_id | integer | not null default nextval('public.societe_soc_id_seq'::text) soc_nom | character varying(200) | Index: societe_pkey primary key btree (soc_id) The code to access it: ====================== class societe(SQLObject): _connection = conn _fromDatabase = True _idName = 'soc_id' p = societe.new(socNom='Adelux', socMail='co...@ad...', socWeb='http://www.adelux.fr') ====================== What's strange is that *if* I set a simple primary key as 'id' in my table (the default that is looked for in SQLObject I guess), it works. It's as if the '_idName' attribute didn't work and wasn't taken into account... Is this a bug? Thanks, Luc Stepniewski -- Luc Stepniewski <ls...@ad...> <http://lstep.free.fr/> Adelux - Securite, Linux Public key: <http://lstep.free.fr/pubkey.txt> Key BC0E3C2A fingerprint = A4FA466C68D27E46B427 07D083ED6340BC0E3C2A |
From: Sidnei da S. <si...@pl...> - 2003-07-31 12:05:10
|
On Thu, Jul 31, 2003 at 11:45:50AM +0200, Luc Stepniewski wrote: | Hello, | | I tried (on PostgreSQL 7.3.3) to use the _fromDatabase=True feature to be able | to use my already created tables (manually created, not with SQLObject). | SQObject chokes on the parsing of the primary key (which is a serial defined | type): | | ValueError: Unknown SQL builtin type: <type 'instance'> for | nextval('public.societe_soc_id_seq'::text) Its a bug yes. The solution is to find out what class 'nextval('public.societe_soc_id_seq'::text)' is (humm... I should put that in the error message) and register a converter to it. There are lots of examples in SQLBuilder.py and Converters.py, but I couldnt catch all the possible classes that would slipt through the sqlRepr function. I just added SQLObjectField yesterday, and a few more, but I didn't added Field for example as I couldn't see where it could be used. []'s -- Sidnei da Silva <si...@pl...> dreamcatching :: making your dreams come true http://dreamcatcher.homeunix.org A year spent in artificial intelligence is enough to make one believe in God. |
From: Luc S. <luc...@ad...> - 2003-07-31 12:53:45
|
On Thursday 31 July 2003 14:02, Sidnei da Silva wrote: > On Thu, Jul 31, 2003 at 11:45:50AM +0200, Luc Stepniewski wrote: > | Hello, > | > | I tried (on PostgreSQL 7.3.3) to use the _fromDatabase=True feature to be > | able to use my already created tables (manually created, not with > | SQLObject). SQObject chokes on the parsing of the primary key (which is a > | serial defined type): > | > | ValueError: Unknown SQL builtin type: <type 'instance'> for > | nextval('public.societe_soc_id_seq'::text) > > Its a bug yes. The solution is to find out what class > 'nextval('public.societe_soc_id_seq'::text)' is (humm... I should put > that in the error message) and register a converter to it. There are > lots of examples in SQLBuilder.py and Converters.py, but I couldnt > catch all the possible classes that would slipt through the sqlRepr > function. I just added SQLObjectField yesterday, and a few more, but I > didn't added Field for example as I couldn't see where it could be used. But why does it work if I don't define the _idName attribute? Isn't there another problem with the use of that attribute which may not be accounted when looking for the primary key? I've looked at Converters.py. I don't understand the way the information is identified. When I look at it, it seems the information is identified only by its basic types. I added an output of obj.__class__ in sqlRepr() in Converters.py to see the class name. The problem is that I get 'SQLObject.SQLBuilder.SQLConstant'. What am I supposed to do this it? SQLObject don't seem to support Bool postgreSQL type, so I looked at what was returned by sqlRepr() when trying to interpret Bool keyword: it returns the same thing: SQLObject.SQLBuilder.SQLConstant Thanks, Luc -- Luc Stepniewski <ls...@ad...> <http://lstep.free.fr/> Adelux - Securite, Linux Public key: <http://lstep.free.fr/pubkey.txt> Key BC0E3C2A fingerprint = A4FA466C68D27E46B427 07D083ED6340BC0E3C2A |
From: Sidnei da S. <si...@pl...> - 2003-07-31 14:28:10
|
On Thu, Jul 31, 2003 at 02:53:28PM +0200, Luc Stepniewski wrote: | But why does it work if I don't define the _idName attribute? Isn't there | another problem with the use of that attribute which may not be accounted | when looking for the primary key? Hummm... it may be because when you set the attribute it uses a SQLConstant, but thats only a wild guess. I haven't actually digged the code. | I've looked at Converters.py. I don't understand the way the information is | identified. When I look at it, it seems the information is identified only by | its basic types. | I added an output of obj.__class__ in sqlRepr() in Converters.py to see the | class name. The problem is that I get 'SQLObject.SQLBuilder.SQLConstant'. | What am I supposed to do this it? | SQLObject don't seem to support Bool postgreSQL type, so I looked at what was | returned by sqlRepr() when trying to interpret Bool keyword: it returns the | same thing: SQLObject.SQLBuilder.SQLConstant Thanks for tracking it. I registered a converter for SQLConstant and a few more friends and added tests. []'s -- Sidnei da Silva <si...@pl...> dreamcatching :: making your dreams come true http://dreamcatcher.homeunix.org A programming language is low level when its programs require attention to the irrelevant. |
From: Ian B. <ia...@co...> - 2003-08-01 02:49:49
|
On Thu, 2003-07-31 at 07:53, Luc Stepniewski wrote: > I've looked at Converters.py. I don't understand the way the information is > identified. When I look at it, it seems the information is identified only by > its basic types. > I added an output of obj.__class__ in sqlRepr() in Converters.py to see the > class name. The problem is that I get 'SQLObject.SQLBuilder.SQLConstant'. > What am I supposed to do this it? > SQLObject don't seem to support Bool postgreSQL type, so I looked at what was > returned by sqlRepr() when trying to interpret Bool keyword: it returns the > same thing: SQLObject.SQLBuilder.SQLConstant It looks like in general the converters aren't respecting the sqlRepr magic method. I checked in a fix for that, which should fix this problem (at least if that's all that's going on here). Ian |