Rafal Krzewski wrote:
>
> "Daniel L. Rall" wrote:
> >
> > John McNally wrote:
> > >
> > > Forgive me for being ignorant but where are the Map related classes ending
> > > up? My guess is that you are leaving them associated with DBBroker. Is
> > > this true?
> > >
> > > DBBroker was born as part of the connection pooling. The association with
> > > the mapping classes was made later and I was thinking the association should
> > > be broken and DBBroker assigned to connection pooling duties only, again.
> > >
> > > Please clue me in.
> >
> > I thought that you were hanlding the map classes and have done nothing
> > with them. I agree that they should be split out...Rafal, can you
> > expand the scheme that you proposed to cover the map classes as well?
>
> OK. We should straighten the issues with these classes as much as
> possible because this is the right moment for shuffling stuff around.
I'm checking in unless I here otherwise. :)
> Today I had a look into the db stuff and here's what I've come up with:
Thanks for looking, your comments are much appreciated.
> DBBroker is a container for multiple ConnectionPools
> (util.db.pool.ConnectionPool) and provides a Fa�ade for them
> getConnection(), getConncetion(String) and releaseConnection(DBConnection).
> (util.db.pool.DBConnection). (It could be even called PooledConnection, as
> in javax.sql, but changing it now would break code).
>
> DBBroker.getDB() method is a fa�ade over ConnectionPool class - hiding the class,
> but exposing it's getDB() method, and should stay inside DBBrokerService.
I have made the ConnectionPool class into a Turbine Service, as
suggested previously...are you saying that it should remain as hidden as
possible? I can revert this change if it's what people prefer.
> DB interface, DBFactory and the implementation should be moved to
> util.db.adapter package.
Done.
> Now. The getDatabaseMap() method (along with deprecated ones) seems to
> be seriously out of place here. The only connection I see is that it's
> dealing with the databases in gneral. :)
>
> I would like to suggest a following solution:
> We should define services.db.MapBrokerService interface, with
> acompanying TurbineMapBrokerService and TurbineMapBroker.
> This service would provide a single access point repository of
> named DatabaseMaps.
>
> One more random thought: maybe we could have services.db.PoolBrokerService
> instead services.db.DBBrokerService.
>
> The old implementation util.db.pool.DBBroker should stay, the class should be marked
> as deprecated and become a wrapper for services.db.TurbinePoolBroker and
> services.db.TurbineMapBroker
I will implement this as well, but I haven't as of yet.
--
Daniel Rall <[EMAIL PROTECTED]>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
