Thread: [SQLObject] picked column type
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Martin B. <mar...@gm...> - 2005-01-13 04:53:53
Attachments:
sqlobject.pickled.patch
|
hi some more tinkering. i want to store lists of stuff. i would use a table for the stuff itself, but i still need to store a variable-length list of indexes to those objects. seems to me like a typical problem, but i have little direct experience with SQL... how does one normally store variable-length lists of indexes or "stuff" with SQL? i saw that Postgres supports an array type, but there doesn't seem to be support for arrays in sqlobject. anyway, so after the binary type support i thought it would be cool to have a PickledCol column type, where pickling and unpickling would occur automatically. i fiddled with this for a short time and came up with the patch below (over 537). i'm not quite sure why toPython gets called multiple times with different types, i didn't take the time to debug the issue yet, but this seems to work. it's fun, you can store anything in the column. cheers, |
From: Oleg B. <ph...@ph...> - 2005-01-13 13:33:55
|
On Wed, Jan 12, 2005 at 11:53:51PM -0500, Martin Blais wrote: > i would use a table for the stuff itself, but i still need to store a > variable-length list of indexes to those objects. seems to me like a > typical problem, but i have little direct experience with SQL... how > does one normally store variable-length lists of indexes or "stuff" > with SQL? Using an additional table and MultipleJoin. > i saw that Postgres supports an array type, but there doesn't seem to > be support for arrays in sqlobject. Not portable. SQLObject is oriented at least on MySQL, PostgreSQl and SQLite. > anyway, so after the binary type support i thought it would be cool to > have a PickledCol column type, where pickling and unpickling would > occur automatically. i fiddled with this for a short time and came up > with the patch below (over 537). i'm not quite sure why toPython gets > called multiple times with different types, i didn't take the time to > debug the issue yet, but this seems to work. it's fun, you can store > anything in the column. The column lokks good, and the test passed. But there are two issues with it. First, whether the column really belongs to col.py; it is not generic enough for my taste; it makes a database too much python-oriented. And second, python docs give warning about security - one must not unpickle data from an untrusted source. Is data from SQL DB trusted enough? What if (un)pickling raise a PickleError? Should the PickleValidator catch it and translate to InvalidField, or return None, or pass it to the user? Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Martin B. <mar...@gm...> - 2005-01-13 14:13:19
|
On Thu, 13 Jan 2005 16:33:43 +0300, Oleg Broytmann <ph...@ph...> wrote: > On Wed, Jan 12, 2005 at 11:53:51PM -0500, Martin Blais wrote: > > i would use a table for the stuff itself, but i still need to store a > > variable-length list of indexes to those objects. seems to me like a > > typical problem, but i have little direct experience with SQL... how > > does one normally store variable-length lists of indexes or "stuff" > > with SQL? > > Using an additional table and MultipleJoin. thanks! :-) i'll look into it. > > i saw that Postgres supports an array type, but there doesn't seem to > > be support for arrays in sqlobject. > > Not portable. SQLObject is oriented at least on MySQL, PostgreSQl and > SQLite. > > > anyway, so after the binary type support i thought it would be cool to > > have a PickledCol column type, where pickling and unpickling would > > occur automatically. i fiddled with this for a short time and came up > > with the patch below (over 537). i'm not quite sure why toPython gets > > called multiple times with different types, i didn't take the time to > > debug the issue yet, but this seems to work. it's fun, you can store > > anything in the column. > > The column lokks good, and the test passed. But there are two issues > with it. First, whether the column really belongs to col.py; it is not > generic enough for my taste; it makes a database too much > python-oriented. > And second, python docs give warning about security - one must not > unpickle data from an untrusted source. Is data from SQL DB trusted > enough? well, given knowledge of some of the application logic, if you can foil some of the data it uses you're always exposing security problems, pickled data or not. you have to know what's going on, and if you do, a pickled type is _really_ handy. i have a friend who writes much of his apps with just index tables and a pickled type (in perl), works well for many of his commercial apps. > What if (un)pickling raise a PickleError? Should the PickleValidator > catch it and translate to InvalidField, or return None, or pass it to > the user? dunno. not familiar enough with sqlobject yet, what do others think? |
From: Oleg B. <ph...@ph...> - 2005-01-14 14:26:10
|
Well, I extended tests and commited the PickleCol at revision 543. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |