The driver is actually in charge of batcher. 2010/3/26 nadav s <[email protected]>
> 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. > -- Fabio Maulo 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.
