the driver could be incharge of batching the queries to gether and
generating the
SqlString object (do the work of CombineCriteriaQueries())

but there's also a different implementation as to get the results from the
reader... for SqlServer multi query its reading the first reader and then
calling reader.NextResult()
and for the ODP multi query its executing none query (and not execute
reader) and getting the results from the cursors (we also have to be aware
of the cursors parameters and their order)
by calling cursor.GetDataReader() for each cursor

not only that, the OracleRefCursor is a sealed class that doesn't inherite
from any significant abstract ado.net class or interface

so i think having the driver handle all of the non-common logic will result
in having too much responsibility in the driver and in this case won't be
the best option IMO

what we could do is letting the batcher (make sense) be in charge of
batching the queries (generating the SqlString) and after execution - be
incharge of retriving the next data reader

this way we won't have different multi queries and criterias classes... and
the batcher is already well aware of the Db type...
the abstract batcher could have the implementations for the current query
batching and the oracle data client batching batcher will override and add
functionality for odp batching

On Fri, Mar 26, 2010 at 10:45 AM, James L <[email protected]> wrote:

> I think it would be better to have the driver provide its own
> formatter / handler for this, and refactor the existing
> MultiCriteriaImpl and MultiQueryImpl to defer to this instead of doing
> the simple string concatenation it is doing now.  That avoids code
> duplication and encapsulates the knowledge in the class that should be
> responsible for it, the driver.
>
> On Mar 25, 5:07 pm, nadav s <[email protected]> wrote:
> > thanks alot tomer.
> >
> > i will try to find time to add it and commit the code to the project
> withing
> > the next month
> > the thing is that the implementation is totally different from the multi
> > criteria with the sql syntax
> > i just wanna make sure i'll do it correctly
> > so if someone from the dev could verify my thoughts:
> >
> > having a base class for multi criteria with the common logic and two
> multi
> > criteria impl classes
> > one called MultiStatementMultiCriteria and AnonymousBlockMultiCriteria
> that
> > create the sql and bind the parameters (the cursors for the anonymous
> block
> > are extra parameters)
> >
> > when creating the concrete multi criteria instance - using the driver to
> > create it, meaning the current drivers that support multi criteria will
> > create the MultiStatementMultiCriteria and the odp driver will create the
> > anonymous block implementation
> > the method for creating the concrete multi criteria will be added to the
> > abstract driver with default implementation - creating the multi
> statement
> > impl, so the drivers code won't be changed, only the odp driver
> >
> > drivers that don't support will cause an exception just like today (the
> > property of IsMultiCriteriaSupport or something like that exists today,
> for
> > the odp driver it will return true of course)
> >
> > also need to add to the sql types the cursor
> >
> > seems about right?
>
> To unsubscribe from this group, send email to nhibernate-development+
> unsubscribegooglegroups.com or reply to this email with the words "REMOVE
> ME" as the subject.
>

To unsubscribe from this group, send email to 
nhibernate-development+unsubscribegooglegroups.com or reply to this email with 
the words "REMOVE ME" as the subject.

Reply via email to