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 > >
