ok the driver prepares the statement to be batched for multi querying now the patch isn't dirty anymore :)
uploaded the code to JIRA: http://216.121.112.228/browse/NH-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel the rar is the good stuff also put in the comments of the attachment the exact (i hope) methods that have changed to help with the merge <http://216.121.112.228/secure/ManageAttachments.jspa?id=15175> On Fri, Mar 26, 2010 at 4:43 PM, Fabio Maulo <[email protected]> wrote: > 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. > 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.
