sqlobject-discuss — All things SQLObject-related

Re: [SQLObject] Feature Request: Can Registry call a factory method if a class is not found?

[Ian B. <ia...@co...>]

Scott Sanders wrote:
> Can I get a yes/no on this?  I would like this to be a integral part of 
> SQLObject.  Even the ability to have multiple factories.

Sorry, I think it was one of those I-need-to-think-about-this emails 
that I put off and then forgot about it.  Feel free to pester if I miss 
things.

> On Oct 29, 2004, at 11:17 AM, Scott Sanders wrote:
> 
>> Ian,
>>
>> I have successfully been using SQLObject svn trunk for a few days now, 
>> without modifications.  I have implemented automatic class generation 
>> by reading information from the database about classes and their 
>> columns and joins.  I did this by extending MetaSQLObject with my own 
>> behavior, and a factory method called getClass(classname), which 
>> checks the registry, and then constructs a new class if the registry 
>> does not contain the proper class.

This sounds very similar to ezSqlObject, except it uses __getattr__ to 
create the classes (e.g., db.User, instead of getClass('user')).

>> The problem I am running into now, is when you have joined classes, 
>> the joined classes have to be explicitly loaded.  In your users/roles 
>> example, my code would have to look something like this:
>> userClass = getClass('user')
>> roleClass = getClass('role') #if this is not called here, user.roles 
>> will not be defined, because the role class is not in the registry
>> user = userClass.get(1)
>> print list(user.roles[0])

So you are creating the joins dynamically as well?  How does that work? 
  How lazy do you need the class creation to be?

I notice there's no .tables() method on connections, just .tableExists() 
-- it's a pretty no-brainer that such a method should exist, returning a 
list of strings.  Would that be enough?  Then you could create all the 
classes at startup.

>> It would great if the registry was allowed to have a factory method 
>> set to attempt automatic class creation if the class does not exist.  
>> If I coded this up as a patch, would it be accepted?

I'm not entirely clear what you are thinking.  Right now the registry 
tracks classes, but it never returns classes.  Instead class references 
are pushed into the places they are needed, using callbacks which are 
triggered on class creation.  So I'm not sure where this would fit.

-- 
Ian Bicking  /  ia...@co...  / http://blog.ianbicking.org

Re: [SQLObject] Feature Request: Can Registry call a factory method if a class is not found?

[Oleg B. <ph...@ph...>]

On Sun, Dec 05, 2004 at 11:21:41AM -0800, Scott Sanders wrote:
> OK, then can I just get an addRegisrty() call

   Every SQLObject has the attribute _registry. What do you want for
addRegistry()?

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Feature Request: Can Registry call a factory method if a class is not found?

[Scott S. <sc...@st...>]

OK, then can I just get an addRegisrty() call, since they are by 
default automatically generated?

Either way is completely acceptable to me, as long as I can run 
SQLObject unmodified.
Thanks
Scott

On Dec 5, 2004, at 11:15 AM, Oleg Broytmann wrote:

> On Sun, Dec 05, 2004 at 10:54:00AM -0800, Scott Sanders wrote:
>> It is working great, except that I have to use
>> my own getClass() method
>
>    Isn't it exactly the callback you need? Just setup your own 
> registry,
> redefine getClass(), and put all of your classes to that registry.
>
> Oleg.
> -- 
>      Oleg Broytmann            http://phd.pp.ru/            
> ph...@ph...
>            Programmers don't die, they just GOSUB without RETURN.
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

Re: [SQLObject] Feature Request: Can Registry call a factory method if a class is not found?

[Oleg B. <ph...@ma...>]

On Sun, Dec 05, 2004 at 10:54:00AM -0800, Scott Sanders wrote:
> It is working great, except that I have to use 
> my own getClass() method

   Isn't it exactly the callback you need? Just setup your own registry,
redefine getClass(), and put all of your classes to that registry.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Feature Request: Can Registry call a factory method if a class is not found?

[Scott S. <sc...@st...>]

I cannot just import the classes, because they don't exist.  I load 
class columns and joins from the database, and then build up a class 
for SQLObject to use.  It is working great, except that I have to use 
my own getClass() method, and have to preload the non-existent classes 
before I use them.  If the regsitry could call my factory method, all 
child classes will automagically be created.

Scott

On Dec 5, 2004, at 10:26 AM, Oleg Broytmann wrote:

> On Sun, Dec 05, 2004 at 09:07:03AM -0800, Scott Sanders wrote:
>>> The problem I am running into now, is when you have joined classes,
>>> the joined classes have to be explicitly loaded.
>
>    I've stumbled over this many times, but I don't have an idea where
> you can load the class from, if its not already loaded. You'd like to
> provide your own callback ("factory function")? Why not just import
> neccessary modules?
>
> Oleg.
> -- 
>      Oleg Broytmann            http://phd.pp.ru/            
> ph...@ph...
>            Programmers don't die, they just GOSUB without RETURN.
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

Re: [SQLObject] Feature Request: Can Registry call a factory method if a class is not found?

[Oleg B. <ph...@ph...>]

On Sun, Dec 05, 2004 at 09:07:03AM -0800, Scott Sanders wrote:
> >The problem I am running into now, is when you have joined classes, 
> >the joined classes have to be explicitly loaded.

   I've stumbled over this many times, but I don't have an idea where
you can load the class from, if its not already loaded. You'd like to
provide your own callback ("factory function")? Why not just import
neccessary modules?

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Thanks Ian & Oleg!

[Oleg B. <ph...@ma...>]

On Sat, Dec 04, 2004 at 11:54:58PM -0500, Brian Beck wrote:
> I know it's often hard to find time, so I'd like to thank both of you 
> (and any other contributors) for all the work you put into this great 
> extension module every day.
> 
> Thanks fellas!

   Thank you for nice words! BTW, I use and enhance SQLObject for our
commercial program (among other things), so the development is
indirectly sponsored :)

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Feature Request: Can Registry call a factory method if a class is not found?

[Scott S. <sc...@st...>]

Can I get a yes/no on this?  I would like this to be a integral part of 
SQLObject.  Even the ability to have multiple factories.

Thanks
Scott

On Oct 29, 2004, at 11:17 AM, Scott Sanders wrote:

> Ian,
>
> I have successfully been using SQLObject svn trunk for a few days now, 
> without modifications.  I have implemented automatic class generation 
> by reading information from the database about classes and their 
> columns and joins.  I did this by extending MetaSQLObject with my own 
> behavior, and a factory method called getClass(classname), which 
> checks the registry, and then constructs a new class if the registry 
> does not contain the proper class.
>
> The problem I am running into now, is when you have joined classes, 
> the joined classes have to be explicitly loaded.  In your users/roles 
> example, my code would have to look something like this:
> userClass = getClass('user')
> roleClass = getClass('role') #if this is not called here, user.roles 
> will not be defined, because the role class is not in the registry
> user = userClass.get(1)
> print list(user.roles[0])
>
> It would great if the registry was allowed to have a factory method 
> set to attempt automatic class creation if the class does not exist.  
> If I coded this up as a patch, would it be accepted?
>
> Thanks,
> Scott
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

[SQLObject] Thanks Ian & Oleg!

[Brian B. <ex...@gm...>]

I know it's often hard to find time, so I'd like to thank both of you 
(and any other contributors) for all the work you put into this great 
extension module every day.

Thanks fellas!

--
Brian Beck
Adventurer of the First Order
http://exogen.cwru.edu

Re: [SQLObject] Postgres 7.2

[Oleg B. <ph...@ma...>]

On Fri, Dec 03, 2004 at 04:19:23PM -0600, Ian Bicking wrote:
> SQLObject is still 
> quite functional with 7.2, but some parts don't work as well.  I think 
> it's sufficient to say that 7.4 is strongly recommended, and perhaps 
> document the parts that do not work with 7.2.  We can disable the 
> related tests once that is documented.

   Aha, "recommended" instead of "required". Sounds good!

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Postgres 7.2

[Ian B. <ia...@co...>]

Oleg Broytmann wrote:
> On Fri, Dec 03, 2004 at 02:12:32PM -0600, Ian Bicking wrote:
> 
>>I get an error on the second nextval.  I don't have a 7.3 server around, 
>>but I'm guessing it will act the same as 7.4 on this.
> 
> 
>    Thank you! Of course I meant 7.3 and higher, so 7.4 is as good.
> 
>    I don't know what to do with it. I've spent good number of hours
> rewriting columnsFromSchema() to make it work with 7.2, and mostly
> succeed. I can now hack into test_sqlobject checking if it is Postgres,
> and if it is 7.2, and list sequences, and drop them... but should I?
> Does anyone interested in Postgres 7.2 support? Or am I the last person
> still using 7.2? Especially now when PostgreSQL team has released
> 8.0beta5 and is approaching 8.0 release...
>    Or should we just drop support for 7.2 and add to the docs
> requirements "Postgres 7.3 or higher"?

Well, I dunno.  We still use Postgres 7.2 here, though just out of 
inertia -- server by server we're upgrading to 7.4.  SQLObject is still 
quite functional with 7.2, but some parts don't work as well.  I think 
it's sufficient to say that 7.4 is strongly recommended, and perhaps 
document the parts that do not work with 7.2.  We can disable the 
related tests once that is documented.

For some viable backends it's unlikely many of these functions will ever 
work, or won't work reliably, e.g. ODBC.  People who use those backends 
will simply have to stay away from certain features, or create workarounds.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

Re: [SQLObject] Postgres 7.2

[Oleg B. <ph...@ma...>]

On Fri, Dec 03, 2004 at 02:12:32PM -0600, Ian Bicking wrote:
> I get an error on the second nextval.  I don't have a 7.3 server around, 
> but I'm guessing it will act the same as 7.4 on this.

   Thank you! Of course I meant 7.3 and higher, so 7.4 is as good.

   I don't know what to do with it. I've spent good number of hours
rewriting columnsFromSchema() to make it work with 7.2, and mostly
succeed. I can now hack into test_sqlobject checking if it is Postgres,
and if it is 7.2, and list sequences, and drop them... but should I?
Does anyone interested in Postgres 7.2 support? Or am I the last person
still using 7.2? Especially now when PostgreSQL team has released
8.0beta5 and is approaching 8.0 release...
   Or should we just drop support for 7.2 and add to the docs
requirements "Postgres 7.3 or higher"?

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] test_sqlobject.py fails on Postgres 7.2

[Ian B. <ia...@co...>]

Oleg Broytmann wrote:
> Hello!
> 
>    ProgrammingError: ERROR:  Relation 'test_s_o1_id_seq' already exists
> 
>    I found the cause for this. In 7.2 DROP TABLE drops the table and all
> indicies but not sequences.
> 
> $ psql test
> test=# \d
>           List of relations
>        Name       |   Type   | Owner 
> ------------------+----------+-------
>  test_s_o1        | table    | phd
>  test_s_o1_id_seq | sequence | phd
> (2 rows)
> 
> test=# DROP TABLE test_s_o1;
> DROP
> test=# \d
>           List of relations
>        Name       |   Type   | Owner 
> ------------------+----------+-------
>  test_s_o1_id_seq | sequence | phd
> (1 row)
> 
> 
>    Can anybody running Postgres 7.3+ confirm whether it drops sequences on
> DROP TABLE?

On 7.4 it seems to drop the sequence when I do:

CREATE TABLE test_table (
   id SERIAL PRIMARY KEY
);
SELECT nextval('test_table_id_seq');
DROP TABLE test_table CASCADE;
SELECT nextval('test_table_id_seq');

I get an error on the second nextval.  I don't have a 7.3 server around, 
but I'm guessing it will act the same as 7.4 on this.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

[SQLObject] test_sqlobject.py fails on Postgres 7.2

[Oleg B. <ph...@ph...>]

Hello!

   ProgrammingError: ERROR:  Relation 'test_s_o1_id_seq' already exists

   I found the cause for this. In 7.2 DROP TABLE drops the table and all
indicies but not sequences.

$ psql test
test=# \d
          List of relations
       Name       |   Type   | Owner 
------------------+----------+-------
 test_s_o1        | table    | phd
 test_s_o1_id_seq | sequence | phd
(2 rows)

test=# DROP TABLE test_s_o1;
DROP
test=# \d
          List of relations
       Name       |   Type   | Owner 
------------------+----------+-------
 test_s_o1_id_seq | sequence | phd
(1 row)


   Can anybody running Postgres 7.3+ confirm whether it drops sequences on
DROP TABLE?

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] Re: .set() fromPython toPython

[Oleg B. <ph...@ph...>]

On Fri, Dec 03, 2004 at 09:51:15AM +0300, Oleg Broytmann wrote:
>    I think .set() has to convert values back toPython.

   Commited at revision 432.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Unicode support?

[Stuart B. <stu...@ca...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Bicking wrote:
| Max Ischenko wrote:
|
|>>> Most modern dbs and python drivers handle this problem
|>>> transparently. At least, that's my experience.
|>>
|>>
|>>    Can you show an example? Using a snippet of code, with a DB API
|>> driver...
|>
|>
|>
|> Guess not. ;-)
|>
|> Just checked with psycopg -- it does requre a parameter to be encoded
|> into something like utf-8.

psycopg2 does it automatically I believe.

|> Either my memory make me a disservice or this psycopg is somehow
|> broken. ;-)
|
| I suspect it's something about Unicode in databases being a pain in the
| ass.  At least, that's what I'm guessing; I've never tried to do it,
| I've only stored ASCII and stuff that I treat as though its binary data.

We happily throw Unicode strings through SQLObject and it gives us
nothing but Unicode strings back. Welcome to the new millenium :-)

To do this, we patched DBAPI._executeRetry and the StringValidator class:

~    def _executeRetry(self, conn, cursor, query):
~        if isinstance(query, unicode):
~            query = query.encode('utf8')
~        else:
~            # raise UnicodeError if it is not valid utf8 already
~            query.decode('utf8')
~        return cursor.execute(query)

class StringValidator(validators.Validator):
~    def fromPython(self, value, state):
~        if isinstance(value, unicode):
~            return value.encode('utf8')
~        return value

~    def toPython(self, value, state):
~        if isinstance(value, str):
~            return value.decode('utf8')
~        return value

This of course should really be done in the PostgreSQL driver somewhere
but the above hack is fine for our needs at the moment. And psycopg2
might make it all irrelevant anyway.

| I might note when I installed postgres on Debian, it asked me questions
| about encoding.  This might imply that encoding setup in an
| installation-wide (not per-database or per-session) fashion.  Then it
| also asked me about how I wanted to format my dates.  I answered ISO,
| but what madness would happen if someone selected US format dates?  I
| doubt psycopg knows anything about what format date the server is using.
|  Maybe these are just defaults, and by explicitly setting up the
| configuration for the connection you can avoid the madness.

PostgreSQL hard codes the locale at initdb time, I believe because the
locale you use for collation order affects index creation and cannot be
changed. It is a pita, because most people really want to use the C
locale and the only way of reverting is to blow away your data directory
and recreate it.

But the locale has nothing to do with the encoding - you can happily
create databases with whatever encoding you like no matter what locale
you selected at initdb time.

- --
Stuart Bishop <stu...@ca...>   http://www.canonical.com/
Canonical Ltd.                              http://www.ubuntulinux.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBsCmmAfqZj7rGN0oRAnzHAJwMSwERoXFFSH1Q67PXEoh87A9juQCeOQbh
bUtoPdnU0pNrA3/PRnGQB+E=
=/jiX
-----END PGP SIGNATURE-----

[SQLObject] .set() fromPython toPython

[Oleg B. <ph...@ph...>]

Hello!

   ._SO_setValue() converts the passed value fromPython to dbValue, and
then dbValue toPython. This allows me to make things like that:

person.birthTime = MyDateTime(1967, 12, 21)
   (where .birthTime is a db column with a getter, a setter, a
validator that converts MyDateTime from/to python to/from string and
store that string in the db)

person.birthTime = "19671221"
   (now ._SO_setValue() will call fromPython which converts the string
to the same string, and toPython which converts the string to MyDateTime
instance)

   All of this is pretty good, convenient and useful. Unfortunately,
.set() doesn't convert values back toPython.

person.set(birthTime = "19671221")
   (Ouch! now .birthTime contains the string instead of MyDateTime
instance)

   I think .set() has to convert values back toPython. I'd like to fix
it, if noone obects.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] Re: Memory leak?

[Martin d'A. <Mar...@s2...>]

> >    selectResults = self._connection._SO_selectOne(self, dbNames)
> > 
> > and fill in the selectResults tuple from within the SQLObject.self (with
> > getattr(self,dbName)) and still call self._SO_selectInit(selectResults)
> > 
> > Is one solution preferable over the other? Should I set self.dirty = True?
> 
> It seems to me the best way to preserve SQLObject behavior without
> introducing a new toggle ( as I previously suggested ) would be to (as
> you suggest) fill out selectResults without issuing a select to
> the database.  

I don't know how to do it without a new toggle. I have something here but 
is it not working yet. Admire a modified section of main.py:

        if not selectResults:
            if (self._fetchValuesOnCreate):
                dbNames = [col.dbName for col in self._SO_columns]
                selectResults = self._connection._SO_selectOne(self, dbNames)
            else:
                names = [col.name for col in self._SO_columns]
                tmp_selectResults = []
                for name in names:
                   tmp_selectResults.append(getattr(self,name))
                selectResults = tuple(tmp_selectResults)
            if not selectResults:
                raise SQLObjectNotFound, "The object %s by the ID %s does not exist" % (self.__class__.__name__, self.id)
        self._SO_selectInit(selectResults)
        self._SO_createValues = {}
        self.dirty = False

The problem is with "tmp_selectResults.append(getattr(self,name))". self
is some sort of object that overloads getattr to go to the database to get
the attribute value!!!

Martin

Re: [SQLObject] Re: Memory leak?

[Martin d'A. <Mar...@s2...>]

On Thu, 2 Dec 2004, Justin Azoff wrote:

> On Thu, 2004-12-02 at 18:25, Ryan Harper wrote:
> > It seems to me the best way to preserve SQLObject behavior without
> > introducing a new toggle ( as I previously suggested ) would be to (as
> > you suggest) fill out selectResults without issuing a select to
> > the database.  
> > 
> > Unless someone sees a reason why SQLObject SHOULD or MUST query the
> > database rather than using the values that were passed to the table I
> > think that would be a good optimization with no interface impact.
> > 
> > Ryan Harper

I can see one reason, but I am not sure it is true: what if you need to 
immediately use an auto_increment value in a subsequent insert for a 
one/many-to-many relationship?

Martin

Re: [SQLObject] Re: Memory leak?

[Justin A. <JA...@ua...>]

On Thu, 2004-12-02 at 18:25, Ryan Harper wrote:
> It seems to me the best way to preserve SQLObject behavior without
> introducing a new toggle ( as I previously suggested ) would be to (as
> you suggest) fill out selectResults without issuing a select to
> the database.  
> 
> Unless someone sees a reason why SQLObject SHOULD or MUST query the
> database rather than using the values that were passed to the table I
> think that would be a good optimization with no interface impact.
> 
> Ryan Harper

There is the previous mentioned case of using sqlbuilder.func.NOW() and
others... Other than that I would certainly welcome the speed boost that
this would give :-)


-- 
-- Justin Azoff
-- Network Performance Analyst

[SQLObject] Re: Memory leak?

[Ryan H. <rh...@sh...>]

>    selectResults = self._connection._SO_selectOne(self, dbNames)
> 
> and fill in the selectResults tuple from within the SQLObject.self (with
> getattr(self,dbName)) and still call self._SO_selectInit(selectResults)
> 
> Is one solution preferable over the other? Should I set self.dirty = True?

It seems to me the best way to preserve SQLObject behavior without
introducing a new toggle ( as I previously suggested ) would be to (as
you suggest) fill out selectResults without issuing a select to
the database.  

Unless someone sees a reason why SQLObject SHOULD or MUST query the
database rather than using the values that were passed to the table I
think that would be a good optimization with no interface impact.

Ryan Harper

Re: [SQLObject] Re: Memory leak?

[Ryan H. <rh...@sh...>]

* Martin d'Anjou <Mar...@s2...> [2004-12-02 16:14]:
> > 2. Avoid issuing the subseqent select to initialize newly created
> > objects (_init() calls selectOne())
> > 
> > Ryan Harper
> 
> The purpose of SQLObject._init() seems to be the initialization of the 
> instance member values. To do that, it needs to fetch the data from the 
> database. But since this is called on object creation, the data should be 
> known without going to the database.
>

I don't mind this being done.  It is a clean design to initialize the
members from the results of the insert.  I don't want that changed,
rather I want something like:

Person(name="Bob",__cache=False,__initObject=False) 

The above telling SQLObject to not add a ref to the connection._cache
and to not bother running _init().

Ryan Harper

[SQLObject] Re: Memory leak?

[Martin d'A. <Mar...@s2...>]

> > 1. caching of newly created objects (inserts)
> > 2. Avoid issuing the subseqent select to initialize newly created
> > objects (_init() calls selectOne())
> > 
> > Ryan Harper
> 
> The purpose of SQLObject._init() seems to be the initialization of the 
> instance member values. To do that, it needs to fetch the data from the 
> database. But since this is called on object creation, the data should be 
> known without going to the database.
>
> Martin

I have two solutions for this problem.

1) put an if around the whole tail end of SQLObject._init() and do not 
call self._SO_selectInit(selectResults)

2) if around the line:

   selectResults = self._connection._SO_selectOne(self, dbNames)

and fill in the selectResults tuple from within the SQLObject.self (with
getattr(self,dbName)) and still call self._SO_selectInit(selectResults)

Is one solution preferable over the other? Should I set self.dirty = True?

Thanks,
Martin

[SQLObject] Re: Memory leak?

[Martin d'A. <Mar...@s2...>]

> 1. caching of newly created objects (inserts)
> 2. Avoid issuing the subseqent select to initialize newly created
> objects (_init() calls selectOne())
> 
> Ryan Harper

The purpose of SQLObject._init() seems to be the initialization of the 
instance member values. To do that, it needs to fetch the data from the 
database. But since this is called on object creation, the data should be 
known without going to the database.

Martin

Re: [SQLObject] Problem with _init (docs could be clearer)

[Carlos R. <car...@gm...>]

On Thu, 02 Dec 2004 10:44:25 -0600, Ian Bicking <ia...@co...> wrote:
> Carlos Ribeiro wrote:
> > It's just a small issue...
> >
> > The section "Initializing the objects" of the documentation mentions
> > that, in order to customize the initialization code, one should
> > override the _init method:
> 
> Noted and documentation corrected.

Thanks, and please, accept my apologies for the tone of the original
message. It was about midnight, and I was just annoyed to find it
after a tiresome day. (thanks to pervasive unittesting, though, I
could catch the error pretty quickly -- one more point for TDD!).

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...