Mike, I'm not feeling offended at all. My opinion is only just my opinion. Inject-ability: The feature is there. You can inject your IBatcherFactory implementation. Inside your batcher you can override DoExecuteBatch and avoid the call of VerifyOutcomeBatched.
On Thu, Apr 22, 2010 at 12:08 PM, mikedoherty <[email protected]>wrote: > Fabio, > > I'm sorry if my question didn't come across very well. I didn't mean > to offend. > > In answer to your points above: > > 1) I didn't raise the defect. I commented on an existing defect in > jira. > 2) I'm not asking you to do the work. I'm volunteering to submit a > patch. In fact I already have a prototype working and wanted to ask > your opinion as I am new to the NHibernate codebase. > 3) I've already forked it. I'm offering to do the additional work to > make this a feature in Nibernate IF that is something you would like > included. > > I fully understand all your points about the fundamental nature of > this check but why prevent people from removing that check if they > know what they are doing. The rest of the framework is really > extensible so why does this part have to be fixed? Also what about > Diego's point about making the validations injectable? NH is really > flexible in other areas. > > At the end of the day I'm volunteering my effort to work with you to > create a solution for something that is a pain point for a few of your > users. If my contribution doesn't fit with your vision of where > NHibernate is going then fair enough. > > Regards, > > Mike > > > On Apr 22, 2:12 pm, 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
