David,
What a cool idea. I was just thinking (in the shower) about this a solution
like this, but using a JDBC wrapper. I still plan on going ahead with my
solution, but in the future I think it would be a smart idea to move it back
into the ra. (Unless someone wants to write the ra wrapper).
-dain
----- Original Message -----
From: "David Jencks" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 17, 2001 4:46 PM
Subject: Re: [JBoss-dev] JDBC SQL Extensions
> On 2001.08.17 16:31:43 -0400 Dain Sundstrom wrote:
> > Sorry for the confusion. There are two issues here.
> >
> > ==================================================
> >
> > Issue1: use of the {fn concat(str1, str2)} style functions.
> >
> > Solution: use fn style functions as default but have override in xml
> > like:
> > <concat-function>CONCAT (?1, ?2)</concat-function>
> > or some thing simmilar.
>
> Conceivable alternate solution:
>
> Since we are now using resource adapters to wrap the db connections, we
> could write resource adapters for each non-compliant db that suitably
> rewrites these functions to something the db will accept. Puts the pain
> where it belongs.
>
> Having a db - specific wrapper-rar might make ManagedConnectionFactory
> configuration a lot simpler too.
> >
> > ==================================================
> >
> > Issue 2: IS EMPTY function. How should I map the following ejb-ql query:
> >
> > SELECT OBJECT(o)
> > FROM Order o
> > WHERE o.lineItems IS EMPTY
> >
> > Solution A:
> >
> > SELECT o.ordernumber
> > FROM Order o
> > WHERE NOT EXISTS (
> > SELECT l.pk
> > FROM Order o, LineItem l
> > WHERE o.ordernumber = l.ordernumber)
> >
> > I like this because it does not use an outer join (thanks Dave Smith).
> > Does
> > it have performance problems?
> >
> > Solution B:
> >
> > SELECT o.ordernumber
> > FROM Order o LEFT OUTER JOIN LineItem l ON o.ordernumber = l.ordernumber
> > WHERE l.ordernumber IS NULL
> >
> > This would be a major pain to map to all vendors.
> >
>
> I think which works better is going to depend on what kind of mistakes are
> in the particular db's optimizer. Naively I would expect (A) to be easier
> to make fast, but I haven't done comparisons. Go for (A) and see if
anyone
> complains and what db.
>
> david jencks
> >
>
>
> >
> >
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
