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
