- 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
