[Opensource] Re: [Opensource] Réf. : Re: [Opensource] isn't it a priority to correct bugs ?

[Michael Rimov]

At 06:38 PM 10/24/2002 +0200, you wrote:



<snip>


>Encouraged by Mike, I just tried again under Expresso 5.0. , connected 
>with a MySql database, in order to try to run deeper into the causes, and 
>trying to trace what happens...
>My app uses 2 dbs : one for the tables of Expresso and one for the real 
>data (configured with hasSetupTables=false through config file)
>
>My app has to retrieve a lot of linked objects (in fact it handles a tree 
>containing recurse nodes), hopefully with the same connection. For that, 
>it counts on the fact that the connection of a DBObject (say the root of a 
>tree) is passed through other linked nodes by building them with 
>constructor invoked in such a way :
>
>linked_node = new DBNode( rootNode.getConnection() );
>
>rootNode having been initialized by by smthg like  :
>DBNode rootNode = DBNode.retrieveFmKey(conn, key);
>
>where conn is a first connection obtained by thePool.getConnection();
>
>The method getConnection() is a method of my specific class DBNode that 
>returns instance var. localConnection of the inherited SecuredDBObject.
>
>--> Here is one pb : this variable that was never null in Expresso 4.02 
>now can be null, so I had to modify DBNode.getConnection() in order to 
>test it and get new connection from the pool in the case of nullity - I 
>don't understand why this var.  localConnection gets null - may be there 
>is a release of connection that didnt happen in 4.02 ? may be I don't have 
>to rely on this variable but use another way ?

I'm sorry, but I'm not following you on this one... could you post a small 
code snippet to show what can now be null that wasn't before??




>--> there must be another pb., linked with the fact I am using one db for 
>config, and one other for date, as I get the message :

Ok, I believe I know what the source of the problem of this issue is.  One 
of the behaviors that was changed. [I forget who submitted the patch] was 
the constructor DBObject(DBConnection)... it was changed so that the 
DBObject's data context (or dbname) was set to that of the 
DBConnection.  For multiple independent data sources, this was indeed a 
correct move... but now I see that it causes problem with other-db maps.

So what I propose as a compromise would be a new constructor:

DBObject(DBConnection, String dataContext);

Which would be identical to the original constructor EXCEPT that the 
DBObject's context would be that of the constructor parameter.  It would 
require that you add these constructor's to your DBObjects, but that way, 
we have better defined behaviors for both other-db-map and independent 
contexts.  What do you think?

HTH!
                                                 -Mike