What we should do with the issue NH-1353 ? Close it because already supported ?
On Thu, Apr 22, 2010 at 12:35 PM, mikedoherty <[email protected]>wrote: > Thanks I'll have a look at injecting my own IBatcherFactory > implementation instead. > > Mike > > On Apr 22, 4:25 pm, Fabio Maulo <[email protected]> wrote: > > 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 > -- Fabio Maulo
