Dieguito querido!! ;) my friend... NH is so injectable that you can change the whole behavior without touch the core. But I know... there are so many injection points that many times it is really difficult to understand which point choose and in many cases what I saw is an addition of a "more granular" injection making understandable the responsibility of each class. Taking this case as example: - You must inject the Dialect - through the dialect you can inject the Drive (you can do the same with a configuration property) - through the Drive you can inject the batch-factory (you can do the same with a configuration property) - through the batch-factory you can inject a real or a fake batcher or a "partially fake batcher"
Instead use all already available injections the proposal is add another configuration-property to avoid the call of one method that is represented by just one code line: Expectations.VerifyOutcomeBatched(totalExpectedRowsAffected, rowsAffected); Perhaps the right direction would be: "Hi friend. I have this need..... the solution I have found is ..... is there another behavior-injection-point ?" Believe me that, in general, the answer is "Yes" but to find it inside +1400 classes is not so easy, I know. On Thu, Apr 22, 2010 at 10:33 AM, Diego Jancic <[email protected]> wrote: > Ohh.. I see, those are good points ;-) > > > On Thu, Apr 22, 2010 at 10:12, Fabio Maulo <[email protected]> wrote: > >> - The JIRA is there >> - I'm not the only one contributor >> - NH is OSS and you can fork it <=== touchable code of this century; NO >> Eliot Ness >> >> My point is: >> Because you can't touch your code you create an issue in NH. >> Because your RDBMS has a very poor pagination you create an issue in NH to >> have a workaround. >> Because your framework does not create a good XYZ you ask more work in NH >> that should be done by NH team but following your rules. >> >> and my point about about untouchable stuff is public: >> http://fabiomaulo.blogspot.com/2009/06/database-eliot-ness-of-it.html >> >> If you will remove the "expectation" check anything may happen during an >> insert/update/delete and you must pray that everything is under your control >> (from optimistic-lock to a simple value of column) inside and outside the >> batcher. >> >> >> On Thu, Apr 22, 2010 at 9:33 AM, Diego Jancic <[email protected]> wrote: >> >>> Why is it 'fundamental' ? Can't NH work without it? It looks like a >>> validation that could be easily removed. >>> I don't need it, and I think Fabio's solution is the best one, however I >>> see no reason to don't add a new feature to NH if the patch is submitted. >>> >>> Maybe there's another solution: make the validations injectable, that way >>> validations can be extended or (although it's not recommended) removed. >>> Came on Fabio, be good with contributors =) >>> >>> >>> On Thu, Apr 22, 2010 at 09:09, Fabio Maulo <[email protected]> wrote: >>> >>>> The check of the expectation is a fundamental check. >>>> I have a proposal for you: change the stored procedure. >>>> You can't touch it ? well... to work with untouchable code is an hard >>>> living; Elliot Ness is not a guy of this century. >>>> >>>> On Thu, Apr 22, 2010 at 7:35 AM, mikedoherty < >>>> [email protected]> wrote: >>>> >>>>> Hi, >>>>> >>>>> I'm not sure if this is the correct place to be asking this question >>>>> but I would like to submit a patch for NH-1353 and have some questions >>>>> about my proposed solution and whether or not it would be suitable. >>>>> >>>>> Basically our team need to be able to turn off the expectation that >>>>> the number of rows returned from the query matches the number expected >>>>> by NHibernate as we have no control over the triggers on our 3rd party >>>>> database. It would appear that we are not alone in this requirement. >>>>> NH-1353 proposes a potential solution to this problem along with a >>>>> patch but it appears that this patch was never accepted. As an >>>>> alternative then I would like to propose an alternative, and hopefully >>>>> more acceptable, solution. >>>>> >>>>> Firstly what I would like to propose is that this expectation can be >>>>> turned off for an individual entity via the class or collection >>>>> mapping. As a result this approach would require a new attribute in >>>>> the hbm schema. Is it acceptable to add new attributes or do you need >>>>> to keep compatibility with the Java configuration schema? >>>>> >>>>> Secondly, assuming a new attribute would be acceptable, what name >>>>> should I give to the new attribute? Looking at the schema the sql- >>>>> insert, sql-update and sql-delete elements allow control over this >>>>> using the "check" attribute. However class already has an attribute >>>>> called check for constraints. Within the code there are two ways of >>>>> referring to this check either as an Expectation or as >>>>> ExecuteUpdateResultCheckStyle so maybe the attribute could be called >>>>> "expectation" or "check-style"? I would appreciate guidance on this >>>>> too. >>>>> >>>>> Thanks in advance, >>>>> >>>>> Mike Doherty >>>>> >>>>> >>>>> -- >>>>> Subscription settings: >>>>> http://groups.google.com/group/nhibernate-development/subscribe?hl=en >>>>> >>>> >>>> >>>> >>>> -- >>>> Fabio Maulo >>>> >>>> >>> >> >> >> -- >> Fabio Maulo >> >> > -- Fabio Maulo
