Thread: [SQLObject] sqlbuilder.func.NOW() bugs?
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Choe, Cheng-D. <whi...@gm...> - 2005-01-31 02:54:40
|
When I upgrade SQLObject to 0.6.1. sqlbuilder.func.NOW( ) make error ---- the code --- class Test(SQLObject): _connection =3D3D conn timestamp =3D3D DateTimeCol( default=3D3Dsqlbuilder.func.NOW() ) t =3D3D Test() ---- end code ---- ---- begin run --- Traceback (most recent call last): File "testSQLObject.py", line 11, in ? t =3D3D Test() File "/usr/local/lib/python2.4/site-packages/sqlobject/main.py", line 890, in __init__ self._create(id, **kw) File "/usr/local/lib/python2.4/site-packages/sqlobject/main.py", line 920, in _create self.set(**kw) File "/usr/local/lib/python2.4/site-packages/sqlobject/main.py", line 774, in set kw[name] =3D3D dbValue =3D3D fromPython(value, self._SO_validatorState) File "/usr/local/lib/python2.4/site-packages/sqlobject/col.py", line 726, in fromPython (self.name, type(value)), value, state) sqlobject.include.validators.InvalidField: expected a datetime in the DateTimeCol 'timestamp', got <type 'instance'> instead. Value: NOW() --- end run --- is usage of sqlbuilder.func.NOW() changed? --=20 Choe, Cheng-Dae(=EC=B5=9C=EC=A0=95=EB=8C=80) Blog: http://www.comdongin.com/ |
From: Oleg B. <ph...@ma...> - 2005-01-31 05:45:47
|
On Mon, Jan 31, 2005 at 11:54:36AM +0900, Choe, Cheng-Dae wrote: > sqlobject.include.validators.InvalidField: expected a datetime in the > DateTimeCol 'timestamp', got <type 'instance'> instead. Value: NOW() > --- end run --- > is usage of sqlbuilder.func.NOW() changed? This is an unintended consequence of the change in DateTimeCol. I'll look into it when I'll have a chance... Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Charles B. <li...@st...> - 2005-01-31 07:12:18
|
Hi, This is probably more of a general database question, but my google searches haven't been turning up many relevant results. Since I'm using SQLObject as my persistence mechanism I thought I'd ask here. Is there a recommended approach to store sorted lists to a database? The specific application I have in mind would be a list that users can assign arbitrary order to based on an assigned rank. As an example, say there are 300 items that people can re-order via a ranking page. (maybe prioritized queue would be a better definition?) My initial thought was to create these lists via a table where every row represented an entry in the list. Each row could have the "item_id" and "rank" value in it. The problem with this approach is that adding a 301st item in the first position would require 300 sql UPDATE statements to re-rank the other items. Clearly this wouldn't scale or perform well. I feel like I must be overlooking an obvious solution. Right now I'm thinking that I should just create a pickle or xml blob of the list and store the whole thing in one row, since I'll probably want to load and save the whole list with every action. Maybe there's a better way though. Any advice? Thanks in advance. -Charles. |
From: Oleg B. <ph...@ph...> - 2005-01-31 06:42:16
Attachments:
col.py.patch
|
On Mon, Jan 31, 2005 at 11:54:36AM +0900, Choe, Cheng-Dae wrote: > class Test(SQLObject): > _connection =3D conn > > timestamp =3D DateTimeCol( default=3Dsqlbuilder.func.NOW() ) Fixed in the trunk, revision 559. The patch is attached. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Choe, Cheng-D. <whi...@gm...> - 2005-01-31 07:19:46
|
Let me know when the bugfix will be released? On Mon, 31 Jan 2005 09:42:07 +0300, Oleg Broytmann <ph...@ph...> wrote: > On Mon, Jan 31, 2005 at 11:54:36AM +0900, Choe, Cheng-Dae wrote: > > class Test(SQLObject): > > _connection =3D3D conn > > > > timestamp =3D3D DateTimeCol( default=3D3Dsqlbuilder.func.NOW() ) >=20 > Fixed in the trunk, revision 559. The patch is attached. >=20 > Oleg. > -- > Oleg Broytmann http://phd.pp.ru/ ph...@ph... > Programmers don't die, they just GOSUB without RETURN. >=20 >=20 >=20 --=20 Choe, Cheng-Dae(=EC=B5=9C=EC=A0=95=EB=8C=80) Blog: http://www.comdongin.com/ |
From: Oleg B. <ph...@ma...> - 2005-01-31 07:40:15
|
On Mon, Jan 31, 2005 at 01:12:05AM -0600, Charles Brandt wrote: > My initial thought was to create these lists via a table where every row > represented an entry in the list. Each row could have the "item_id" and > "rank" value in it. This *is* the recommended approach. > The problem with this approach is that adding a 301st > item in the first position would require 300 sql UPDATE statements to > re-rank the other items. Clearly this wouldn't scale or perform well. It depends of where the rank comes from. If it is your private column you can update in one statemnt: UPDATE list_table SET rank=rank+1 WHERE... But if ranks come from a user - you have to issue many UPDATEs. The approach is as scalable as the user itself. You cannot expect a user to update a million ranks, right? So don't worry - you have to issue as many UPDATEs as the user can update manually. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Charles B. <li...@st...> - 2005-01-31 08:16:39
|
Hi Oleg, Thanks for the response. > It depends of where the rank comes from. If it is your private column > you can update in one statemnt: > > UPDATE list_table SET rank=rank+1 WHERE... Is there a way to issue custom update statements like this with SQLObject, or would it be easier to make a direct call in this case? > But if ranks come from a user - you have to issue many UPDATEs. The > approach is as scalable as the user itself. You cannot expect a user to > update a million ranks, right? So don't worry - you have to issue as > many UPDATEs as the user can update manually. Rank would definitely be data that comes from the user, but I was hoping to add logic to assist with the updates. So if a user assigns a new rank of 4 to the 300th item in currently ordered list, I'd like the application to automatically update the current items in position 4-299 with their new position of +1 (5-300 respectively). In this case I could see applying the above mentioned UPDATE with customized WHERE. I guess the number of UPDATE statements required would still be limited by the number of actual changes the user makes to rank. I just wanted to avoid individual UPDATEs for every row in the +1 scenario. As long as there are a small number of combined UPDATEs that shouldn't be as bad. Thanks again! -Charles |
From: Oleg B. <ph...@ph...> - 2005-01-31 08:28:41
|
On Mon, Jan 31, 2005 at 02:16:32AM -0600, Charles Brandt wrote: > > UPDATE list_table SET rank=rank+1 WHERE... > > Is there a way to issue custom update statements like this with SQLObject, Probably no. SQLObjects correspond to separate rows, manipulating an object updates only its row. > or would it be easier to make a direct call in this case? You can use connection object and sqlbuilder module. Something lie that: dbConn = MyTable.connection dbConn.query("UPDATE my_table SET rank = rank+1 WHERE"...) or may be: from sqlobject.sqlbuilder import table, Update dbConn.query(Update(table.my_table, {"rank": "rank+1"}, where=...)) Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Oleg B. <ph...@ph...> - 2005-01-31 08:43:42
|
On Mon, Jan 31, 2005 at 02:35:48AM -0600, Charles Brandt wrote: > > from sqlobject.sqlbuilder import table, Update > > dbConn.query(Update(table.my_table, {"rank": "rank+1"}, where=...)) This must be dbConn.query(dbConn.sqlrepr(Update(table.my_table, {"rank": "rank+1"}, where=...))) Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Kevin D. <da...@gm...> - 2005-02-01 13:54:55
|
On Mon, 31 Jan 2005 10:40:06 +0300, Oleg Broytmann <ph...@ma...> wrote: > On Mon, Jan 31, 2005 at 01:12:05AM -0600, Charles Brandt wrote: > > My initial thought was to create these lists via a table where every row > > represented an entry in the list. Each row could have the "item_id" and > > "rank" value in it. > > This *is* the recommended approach. One interesting thing of note is that Hibernate will manage this for you. A List column type would be a cool addition to SQLObject, but since I'm not volunteering to create one right now, I'll just leave it at that. ;) Kevin |