Thread: [SQLObject] Hook for .new() method?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

What's the best way to hook some code into the .new()? Basically, I need 
to run some code after an object is instantiated for the first time. Is 
this what the _init() method is for?

...Edmund.

Just with new, like:

def new(cls, **kw):
    obj = super(cls).new(**kw)
    # ... do stuff ...
    return obj
new = classmethod(new)

On Mon, 2003-06-09 at 00:06, Edmund Lian wrote:
> What's the best way to hook some code into the .new()? Basically, I need 
> to run some code after an object is instantiated for the first time. Is 
> this what the _init() method is for?
> 
> ...Edmund.
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

Is there anyway to pass pure SQL through to the database? I was thinking 
that if performance is an issue, then under some circumstances, it would 
be nice to be able to override selected object methods and use pure SQL 
to do things, I think.

The specific example I'm thinking of is a situation where a table needs 
to have N rows inserted into it, and the data are from other tables. 
Right now, I'd have to write a loop to do this, emitting at least N 
queries. If I could pass SQL through, I could replace the loop with just 
one SQL statement.

Is this a good idea?

...Edmund.

On Mon, 2003-06-09 at 21:05, Edmund Lian wrote:
> Is there anyway to pass pure SQL through to the database? I was thinking 
> that if performance is an issue, then under some circumstances, it would 
> be nice to be able to override selected object methods and use pure SQL 
> to do things, I think.

Yes, the connections have a query(sql) method, with no return value. 
There's also an attribute conn, which is the actual connection object. 
So long as you aren't using cacheValues, or you aren't modifying rows
that could have instantiated SQLObject instances, it shouldn't be a
problem.

> The specific example I'm thinking of is a situation where a table needs 
> to have N rows inserted into it, and the data are from other tables. 
> Right now, I'd have to write a loop to do this, emitting at least N 
> queries. If I could pass SQL through, I could replace the loop with just 
> one SQL statement.
>
> Is this a good idea?

That might be easiest.  It would be reasonable to support this sort of
insertion directly, kind of like .set() updates multiple attributes at
once.  But I'm not sure how to handle the ID generation, assuming you
want a way to get the newly created objects back; maybe it just wouldn't
have a meaningful return, and you'd have to retrieve the new objects via
.select or some other manner.  I don't think that would be too hard to
implement.

  Ian

Ian Bicking wrote:

> Yes, the connections have a query(sql) method, with no return value. 
> There's also an attribute conn, which is the actual connection object. 
> So long as you aren't using cacheValues, or you aren't modifying rows
> that could have instantiated SQLObject instances, it shouldn't be a
> problem.

This would be tricky... I thought that just invalidating the cache would 
do the trick, but what if the cache contains uncommitted changes? 
Hmmm... in the case of absolutely new objects, this won't be an issue 
but I think monkeying with data that might already be in the cache is 
problematic.

...Edmund.

I have an ugly system in place that i think catches all the cases of stale
objects I've used SQLObject for so far, with one caveat. In pseduo-code:

perform SQL
for id in modifiedIDs:
  val = connection.cache.get(class, id)
  connection.cache.purge(class, id)
  if val is not None: # cached value exists!
    # rather than decipher all the SQL that was modified
    newVal = class(id)
    val.__dict__ = newVal.__dict__

The downside to this is that the versions that existed before this operation
are now separated from the cache, and therefore don't act as singleton cached
objects anymore.

The fix would be to have a .reloadFromDB() or similar (.reload() might be
sufficient?) that could reload an object in-place (which just calls
_SO_selectOne()/selectInit?), and then this is easy code. (The only challenge
now is knowing which IDs to reload, or to query the entire store and reload
all... just don't invalidate the cached objects! :)

- Luke

Quoting Edmund Lian <el...@in...>:

> Ian Bicking wrote:
>
> > Yes, the connections have a query(sql) method, with no return value.
> > There's also an attribute conn, which is the actual connection object.
> > So long as you aren't using cacheValues, or you aren't modifying rows
> > that could have instantiated SQLObject instances, it shouldn't be a
> > problem.
>
> This would be tricky... I thought that just invalidating the cache would
> do the trick, but what if the cache contains uncommitted changes?
> Hmmm... in the case of absolutely new objects, this won't be an issue
> but I think monkeying with data that might already be in the cache is
> problematic.
>
> ...Edmund.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>

--
 i find your contempt for naked feet curious.

I think I've come across a bug, but it could be the way I've overridded 
an attribute.

Here's the class (minus join and table name declarations):

class RequestData(SQLObject):
         _columns = [
         IntCol("requestId", foreignKey="Request", notNone=True),
         IntCol("fieldId", foreignKey="Field", notNone=True),
         StringCol("value", default=None)]

     def _get_value(self):
         val = self._SO_get_value()
         return cvtGet[self.field.dataType](val)

     def _set_value(self, val):
         try:
             val = cvtSet[self.field.dataType](val)
         except:
             raise
         self._SO_set_value(val)

Here's what happens:

  >>> r = RequestData.new(requestId=2006, fieldId=500)
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "/usr/lib/python2.2/site-packages/SQLObject/SQLObject.py", line 
797, in new
     setattr(inst, name, value)
   File "/home/elian/mefa/Contexts/FDS/Lib/FdsApi.py", line 209, in 
_set_value
     val = cvtSet[self.field.dataType](val)
   File "<string>", line 1, in <lambda>
AttributeError: 'RequestData' object has no attribute '_SO_val_fieldId'

I'm mystified as to why SQLObject is trying to run the _set_value() 
method on fieldId...

...Edmund.

Matt Goodall wrote:

 > The problem is probably best demonstrated by (untested) example with a
 > description of what happens inside SQLObject's caches:
 >
 >   id = Obj.new(col1='a', col2='b')
 >   # added to cache with key == int(1)
 >
 >   o = Obj(id)
 >   # found in cache with key == int(1)
 >
 >   o = Obj(str(id)) # note the cast to a string
 >   # reads from database, adds to cache with key == str(1)
 >   # Eek, two objects now in cache!

Argh! This problem is very easy to run into. For example, if you pass an 
object ID to another page as a field variable, then it is all too easy 
to forget that you have to cast the value back to an integer before 
using it.

Example:

 From one servlet that has fiddled with obj1 = MyObject(3), redirect to 
another page with a URL like http://my.url/Index?id=3

Then in the Index.py servlet:
id = self.request().field("id")
obj2 = MyObject(id)

Oops! obj1 and obj2 aren't the same objects anymore! It's just too easy 
to do this!!

...Edmund.

Ian Bicking wrote:

> Just with new, like:
> 
> def new(cls, **kw):
>     obj = super(cls).new(**kw)
>     # ... do stuff ...
>     return obj
> new = classmethod(new)
> 
> 
> On Mon, 2003-06-09 at 00:06, Edmund Lian wrote:
> 
>>What's the best way to hook some code into the .new()? Basically, I need 
>>to run some code after an object is instantiated for the first time. Is 
>>this what the _init() method is for?

Hmmm... This doesn't seem to work. When I do this, I get an AttributeError:

     obj = super(cls).new(**kw)
AttributeError: 'super' object has no attribute 'new'

I know that there are some bugs in the super method of Python 2.2. Is 
this one of them? If so, how can I work around it?

...Edmund.

I'm using SQLObject (0.3) in a project at the moment, and I've hit a 
couple of bugs (which seem to be well-known already, so I haven't 
reported them, and just used the patches mentioned in the archives etc.)

I've seen several mentions of the next version, and I was just wondering 
when it was likely to be released? Should I keep using 0.3, or should I 
be using CVS?

Thanks,
Christian

On Wed, 2003-06-11 at 23:21, xtian wrote:
> I'm using SQLObject (0.3) in a project at the moment, and I've hit a 
> couple of bugs (which seem to be well-known already, so I haven't 
> reported them, and just used the patches mentioned in the archives etc.)
> 
> I've seen several mentions of the next version, and I was just wondering 
> when it was likely to be released? Should I keep using 0.3, or should I 
> be using CVS?

I'm planning a release Real Soon.  Right now I just want to finish
redoing the documentation, there shouldn't be any other big changes.  So
CVS is a decent basis for work.

  Ian

Thread: [SQLObject] Hook for .new() method?

SQLObject is a Python ORM.

sqlobject-discuss