cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Huss <johnth...@gmail.com>
Subject Re: cayenne.adapter.[domain].[node] property
Date Mon, 24 Dec 2012 13:24:52 GMT
On Monday, December 24, 2012, Andrus Adamchik wrote:

>
> > Is it necessary to open a connection to the DB to get the metdata in
> order
> > to detect the adapter?  Couldn't you just look at the jdbc url scheme?
>
> Yes. All we have available to Cayenne is a DataSource, which doesn't have
> access to the driver, and can encapsulate various kinds of connection
> pools, which prevents any reliable assertions.
>
> > For migrations I'd like to allow for DB specific sql to be put in
> separate
> > files and then choose the correct file based on which DB is actually
> being
> > used.  I was looking at the Adapter classname for this, but if
> AutoAdapter
> > is used I can't tell what which DB it is.  So would the jdbc url be a
> > reliable source for this info?
>
> > Relatedly, what if AutoAdapter replaced itself with the actual adapter
> > after it was detected?  Wouldn't that be better that delegating?
>
> If possible, I'd like to avoid breaking the decorator. This goes against
> intentional encapsulation of the details.
>
> So can your own code rely on DB metadata, just like various
> DbAdapterDetectors do? A very rich DB information is readily available and
> does not require breaking encapsulation. E.g.:
>
> String jdbcUrl = dataSource.getConnection().getMetadata().getURL();
>
> String dbLabel =
> dataSource.getConnection().getMetadata().getDatabaseProductName();
>
> You said multiple times that you don't want to open a DB connection. But
> why? It should solve all your problems without resorting to "instanceof"
> and such.


This last question is coming from something different.  Opening a
connection is fine. I was just curious why it was neccessary, which you
answered very well.

My issue above was just that I didn't want to open the connection until I
started using it.  Sometimes I have DataNodes that can't be used all the
time because its for a different DB vendor, or for a remote DB that I need
to open a VPN connection to access, etc.  so it's important that only the
used nodes will open connections; and they do now that I changed the
registration of the extended types.


> Andrus
>
>
>
>
>
> On Dec 22, 2012, at 12:45 AM, John Huss <johnthuss@gmail.com<javascript:;>>
> wrote:
>
> > Is it necessary to open a connection to the DB to get the metdata in
> order
> > to detect the adapter?  Couldn't you just look at the jdbc url scheme?
> >
> > For migrations I'd like to allow for DB specific sql to be put in
> separate
> > files and then choose the correct file based on which DB is actually
> being
> > used.  I was looking at the Adapter classname for this, but if
> AutoAdapter
> > is used I can't tell what which DB it is.  So would the jdbc url be a
> > reliable source for this info?
> >
> > Relatedly, what if AutoAdapter replaced itself with the actual adapter
> > after it was detected?  Wouldn't that be better that delegating?
> >
> >
> > On Mon, Dec 17, 2012 at 12:45 AM, Andrus Adamchik <
> andrus@objectstyle.org <javascript:;>>wrote:
> >
> >>
> >> On Dec 16, 2012, at 1:48 AM, John Huss <johnthuss@gmail.com<javascript:;>>
> wrote:
> >>>>
> >>>>> My problem with AutoAdapter is that is causes a connection to be
> opened
> >>>>> immediately whereas a hard coded adapter does not.  Does it have
to
> do
> >>>>> that?
> >>>>
> >>>> It shouldn't. Could you provide a stack trace of the call that starts
> >> the
> >>>> connection? Maybe there's something preceding AutoAdapter
> >> initialization,
> >>>> like connection pool creation?
> >>>
> >>>
> >>> Ok, deeper down I was calling
> >>>    dataNode.getAdapter().getExtendedTypes().registerType(...)
> >>> which was forcing the adapter to be loaded.  This appears not to happen
> >> if
> >>> I use the DI binding instead.  So problem solved!
> >>
> >> Cool. Yeah, a notion of ownership of certain objects by certain other
> >> objects (adapter owns ExtendedType, adapter owns PkGenerator, etc) is
> being
> >> obsoleted by DI, but is still reflected in the API. We'll be gradually
> >> cleaning this up.
> >>
> >> Andrus
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message