Thread: [SQLObject] Ignoring some columns
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Jorge G. <go...@ie...> - 2005-09-12 19:12:17
|
Hi! Is it possible to instruct SQLObject to ignore some columns that will be filled automatically by triggers? I have some tables where we have a constant struture for some inspection purposes that get filled automatically by triggers and I wanted SQLObject ignoring them... Is it possible? They are of the type: created_by varchar(20), (incluido_por) last_updated_by varchar(20), (alterado_por) created_at timestamp with time zone, (incluido_em) last_updated_at timestamp with time zone (ultima_alteracao) (The names inside the parenthesis are the ones used at the table, in brazilian portuguese) I didn't want passing fake values on each and every class that I have... One of my mapping classes is: class EfeitoCritico(sqlobject.SQLObject): _connection = connection _cacheValues = False _table = 'efeitos_criticos' _idName = 'efeito_id' _lazyUpdate = True _fromDatabase = True It is mapping a PostgreSQL table with this structure: neo=# \d efeitos_criticos Tabela "public.efeitos_criticos" Coluna | Tipo | Modificadores ------------------+--------------------------+------------------------------------------------------------------------- efeito_id | integer | not null default nextval('public.efeitos_criticos_efeito_id_seq'::text) nome | character varying(255) | not null incluido_em | timestamp with time zone | ultima_alteracao | timestamp with time zone | incluido_por | character varying(20) | alterado_por | character varying(20) | Índices: "efeitoscriticos_pkey" PRIMARY KEY, btree (efeito_id) "idx_efeitos_criticos_nome_uniq" UNIQUE, btree (nome) Gatilhos: tbi_efeitos_criticos BEFORE INSERT ON efeitos_criticos FOR EACH ROW EXECUTE PROCEDURE f_tbi_inclusao() tbu_efeitos_criticos BEFORE UPDATE ON efeitos_criticos FOR EACH ROW EXECUTE PROCEDURE f_tbu_alteracao() And when I try creatin a new row, I get the following error: >>> import db_map >>> a = db_map.EfeitoCritico(nome='teste4') Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.4/site-packages/sqlobject/main.py", line 890, in __init__ self._create(id, **kw) File "/usr/lib/python2.4/site-packages/sqlobject/main.py", line 915, in _create raise TypeError, "%s() did not get expected keyword argument %s" % (self.__class__.__name__, column.name) TypeError: EfeitoCritico() did not get expected keyword argument incluidoEm >>> (db_map does the connection and has the definition of the EfeitoCritico class in it) I don't understand why it is asking for the value of incluidoEm when I declared it as being nullable. I'm using Python 2.4.1 and SQLObject 0.6.1. -- Jorge Godoy <go...@ie...> |
From: Oleg B. <ph...@ma...> - 2005-09-12 19:27:38
|
On Mon, Sep 12, 2005 at 03:47:52PM -0300, Jorge Godoy wrote: > I don't understand why it is asking for the value of incluidoEm when I > declared it as being nullable. > > I'm using Python 2.4.1 and SQLObject 0.6.1. SQLObject 0.6.1 is really too old and too buggy. Please try your code with SQLObject 0.7b1. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Jorge G. <go...@ie...> - 2005-09-12 19:56:28
|
Oleg Broytmann <ph...@ma...> writes: > On Mon, Sep 12, 2005 at 03:47:52PM -0300, Jorge Godoy wrote: > > I don't understand why it is asking for the value of incluidoEm when I > > declared it as being nullable. > > > > I'm using Python 2.4.1 and SQLObject 0.6.1. > > SQLObject 0.6.1 is really too old and too buggy. Please try your code > with SQLObject 0.7b1. Weird. I accessed the website today and it was the latest version listed in there. See the "News" section at http://www.sqlobject.org/ or click on the "Download" option at the left side menu and the only choice is 0.6.1... Even showing all files at SourceForge shows 0.6.1 as the latest release. Where can I get 0.7b1? Thanks for your help. -- Jorge Godoy <go...@ie...> |
From: Oleg B. <ph...@ma...> - 2005-09-12 20:33:35
|
On Mon, Sep 12, 2005 at 04:50:28PM -0300, Jorge Godoy wrote: > > SQLObject 0.6.1 is really too old and too buggy. Please try your code > > with SQLObject 0.7b1. > > Weird. I accessed the website today and it was the latest version listed in > there. See the "News" section at http://www.sqlobject.org/ or click on the See 0.7 in the News: http://sqlobject.org/docs/News.html#sqlobject-0-7-0 > "Download" option at the left side menu and the only choice is 0.6.1... Even > showing all files at SourceForge shows 0.6.1 as the latest release. It seems there is no official 0.7b tarball yet. > Where can I get 0.7b1? Get it directly from the Subversion repository or use my tarballs: http://phd.pp.ru/Software/Python/misc/SQLObject/ I can assure you even these "bleeding edge" tarballs are more stable and less buggy than SQLObject 0.6.1. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ian B. <ia...@co...> - 2005-09-12 20:43:17
|
Oleg Broytmann wrote: >>Where can I get 0.7b1? > > > Get it directly from the Subversion repository or use my tarballs: > http://phd.pp.ru/Software/Python/misc/SQLObject/ > I can assure you even these "bleeding edge" tarballs are more stable and > less buggy than SQLObject 0.6.1. There's also the Cheese Shop page: http://cheeseshop.python.org/pypi/SQLObject/0.7b1 though I don't know why 0.6.1 shows up as the default version. But anyway, the subversion repository has a handful of bugfixes that aren't in 0.7b1. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Oleg B. <ph...@ph...> - 2005-09-12 21:02:00
|
On Mon, Sep 12, 2005 at 03:42:48PM -0500, Ian Bicking wrote: > There's also the Cheese Shop page: > > http://cheeseshop.python.org/pypi/SQLObject/0.7b1 IWBN to see tarballs also on the site and at SF. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ian B. <ia...@co...> - 2005-09-12 21:19:54
|
Oleg Broytmann wrote: > On Mon, Sep 12, 2005 at 03:42:48PM -0500, Ian Bicking wrote: > >>There's also the Cheese Shop page: >> >>http://cheeseshop.python.org/pypi/SQLObject/0.7b1 > > > IWBN to see tarballs also on the site and at SF. Once 0.7 is out I'd like to drop SF downloads, since they are annoying, both for uploading and downloading. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Jorge G. <go...@ie...> - 2005-09-12 21:19:02
|
Ian Bicking <ia...@co...> writes: > Oleg Broytmann wrote: > >>Where can I get 0.7b1? > > Get it directly from the Subversion repository or use my tarballs: > > http://phd.pp.ru/Software/Python/misc/SQLObject/ > > I can assure you even these "bleeding edge" tarballs are more stable and > > less buggy than SQLObject 0.6.1. > > There's also the Cheese Shop page: > > http://cheeseshop.python.org/pypi/SQLObject/0.7b1 > > though I don't know why 0.6.1 shows up as the default version. But anyway, > the subversion repository has a handful of bugfixes that aren't in 0.7b1. Thanks, Ian. I just found it misleading that the main page on the website still pointed to 0.6.1. I got Oleg's tarball and I need to update my classes (thanks God that I've just written 20 of them -- there will be more than 400 if the structure is similar to 0.6.1...) to the new requirements and repeat the test. Oleg, as a suggestion, how about making a symlink to something like "SQLObject-oleg-latest.tar.bz2"? :-) It would be interesting to keep up with your tarballs when there's something new at the SVN tree. Be seeing you, -- Jorge Godoy <go...@ie...> |
From: Jorge G. <go...@ie...> - 2005-09-12 20:56:29
|
Oleg Broytmann <ph...@ma...> writes: > > Where can I get 0.7b1? > > Get it directly from the Subversion repository or use my tarballs: > http://phd.pp.ru/Software/Python/misc/SQLObject/ > I can assure you even these "bleeding edge" tarballs are more stable and > less buggy than SQLObject 0.6.1. Done. I'll be trying it and will report if it worked or not. Thanks. -- Jorge Godoy <go...@ie...> |
From: Oleg B. <ph...@ma...> - 2005-09-12 21:04:32
|
On Mon, Sep 12, 2005 at 05:53:30PM -0300, Jorge Godoy wrote: > Done. I'll be trying it and will report if it worked or not. There are some difference in API between SQLObject 0.6 and 0.7, mostly in the area of "sqlmeta". But probably if you ignore all deprecation warnings almost any code can be run directly with 0.7, I think. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ian B. <ia...@co...> - 2005-09-12 21:12:55
|
Oleg Broytmann wrote: > On Mon, Sep 12, 2005 at 05:53:30PM -0300, Jorge Godoy wrote: > >>Done. I'll be trying it and will report if it worked or not. > > > There are some difference in API between SQLObject 0.6 and 0.7, mostly > in the area of "sqlmeta". But probably if you ignore all deprecation > warnings almost any code can be run directly with 0.7, I think. There are regression tests to that effect (tests/*_old.py), so yes, it shouldn't cause problems. Right now (in svn) you can do sqlobject.setDeprecationLevel(warning=None, exception=None) to turn off warnings. Though anything that gives a warning in 0.7 (assuming you keep the default warning level) should disappear in 0.8. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Oleg B. <ph...@ph...> - 2005-09-13 08:43:04
|
On Mon, Sep 12, 2005 at 04:12:29PM -0500, Ian Bicking wrote: > There are regression tests to that effect (tests/*_old.py) I was always curious what are those "old"s and why are they still there! (-: Now I understand! PS. Do you still need test_conngetter.py? Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ian B. <ia...@co...> - 2005-09-13 15:31:52
|
Oleg Broytmann wrote: > On Mon, Sep 12, 2005 at 04:12:29PM -0500, Ian Bicking wrote: > >>There are regression tests to that effect (tests/*_old.py) > > > I was always curious what are those "old"s and why are they still there! > (-: Now I understand! > > PS. Do you still need test_conngetter.py? Hmm... yeah, that test all out of date. I just deleted it. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Jorge G. <go...@ie...> - 2005-09-12 21:50:05
|
Oleg Broytmann <ph...@ma...> writes: > There are some difference in API between SQLObject 0.6 and 0.7, mostly > in the area of "sqlmeta". But probably if you ignore all deprecation > warnings almost any code can be run directly with 0.7, I think. Ian Bicking <ia...@co...> writes: > There are regression tests to that effect (tests/*_old.py), so yes, it > shouldn't cause problems. Right now (in svn) you can do > sqlobject.setDeprecationLevel(warning=None, exception=None) to turn off > warnings. Though anything that gives a warning in 0.7 (assuming you keep the > default warning level) should disappear in 0.8. I'll update the classes. If I'll be using the new version, I prefer following its rules. Specially if those things will be deprecated soon. I'm reading the docs right now to update the classes. You'll hear from me tomorrow :-) -- Jorge Godoy <go...@ie...> |
From: Jorge G. <go...@ie...> - 2005-09-13 14:58:07
|
Jorge Godoy <go...@ie...> writes: > I'll update the classes. If I'll be using the new version, I prefer following > its rules. Specially if those things will be deprecated soon. > > I'm reading the docs right now to update the classes. > > > You'll hear from me tomorrow :-) OK... I missed documentation on the use of "sqlmeta" class. I'll see if I can write some and contribute later, since I have to take a look at the code and see if there are any gotchas. :-) Anyway, on with the updating... :-) All I had to do to upgrade all my classes from 0.6.1 to 0.7b1 was creating a new class "sqlmeta" inside every class I had and moving "_*" to "*" inside of it (i.e., removing the "_" from the attributes). This gave me no warning of deprecation and everything worked. My original problem was solved -- I just have to leave those automatic columns as nullable and that's it. Be seeing you, -- Jorge Godoy <go...@ie...> |
From: Robert F. <fo...@zi...> - 2005-09-13 15:12:30
|
for how to use sqlmeta see http://webwareforpython.org/archives/message/20050819.140932.8ba5e893.en.html snip: class TableA(SQLObject): class sqlmeta: table = 'bob.table_a' idName = 'table_a_id' col1 = StringCol() col2 = StringCol() regards, robert Jorge Godoy wrote: >Jorge Godoy <go...@ie...> writes: > > > >>I'll update the classes. If I'll be using the new version, I prefer following >>its rules. Specially if those things will be deprecated soon. >> >>I'm reading the docs right now to update the classes. >> >> >>You'll hear from me tomorrow :-) >> >> > >OK... I missed documentation on the use of "sqlmeta" class. I'll see if I >can write some and contribute later, since I have to take a look at the code >and see if there are any gotchas. :-) > > >Anyway, on with the updating... :-) > >All I had to do to upgrade all my classes from 0.6.1 to 0.7b1 was creating a >new class "sqlmeta" inside every class I had and moving "_*" to "*" inside of >it (i.e., removing the "_" from the attributes). This gave me no warning of >deprecation and everything worked. > >My original problem was solved -- I just have to leave those automatic columns >as nullable and that's it. > > >Be seeing you, > > -- the idea is to keep the green alien landing craft from taking up humans from the ground and changing them into mutants. a mutant is very dangerous to you, because it flies faster than you do and shoots at you. |
From: Jorge G. <go...@ie...> - 2005-09-13 15:52:41
|
Robert Forkel <fo...@zi...> writes: > for how to use sqlmeta see > http://webwareforpython.org/archives/message/20050819.140932.8ba5e893.en.html > > snip: > class TableA(SQLObject): > class sqlmeta: > table = 'bob.table_a' > idName = 'table_a_id' > col1 = StringCol() > col2 = StringCol() > > regards, > robert This is exactly what I did and what I told on the message that I had to do to get it working. I missed the docs *with* SQLObject. And I have to check the source to see if that's just it or if there are more options that can be used inside this sqlmeta class. But thanks for the URL :-) I'll also check it. Be seeing you, -- Jorge Godoy <go...@ie...> |
From: Oleg B. <ph...@ma...> - 2005-09-13 15:13:30
|
On Tue, Sep 13, 2005 at 11:48:21AM -0300, Jorge Godoy wrote: > OK... I missed documentation on the use of "sqlmeta" class. I'll see if I > can write some and contribute later It would be very kind of you! Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ian B. <ia...@co...> - 2005-09-13 15:35:46
|
Jorge Godoy wrote: > Jorge Godoy <go...@ie...> writes: > > >>I'll update the classes. If I'll be using the new version, I prefer following >>its rules. Specially if those things will be deprecated soon. >> >>I'm reading the docs right now to update the classes. >> >> >>You'll hear from me tomorrow :-) > > > OK... I missed documentation on the use of "sqlmeta" class. I'll see if I > can write some and contribute later, since I have to take a look at the code > and see if there are any gotchas. :-) This might be helpful reading for you: http://sqlobject.org/docs/interface.py.html sqlmeta is described by Isqlmeta. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Jorge G. <go...@ie...> - 2005-09-13 16:02:04
|
Ian Bicking <ia...@co...> writes: > This might be helpful reading for you: > http://sqlobject.org/docs/interface.py.html > > sqlmeta is described by Isqlmeta. Thank you! I'll check it before contributing something. It is a bit hidden at the interfaces description. -- Jorge Godoy <go...@ie...> |