There's the other side of the story too where the dialects teach the core developers how and if something can be implemented to work across databases.
Also consider standard functions. Each dialect provider would need to remember to check for non-interface additions. What about having something like NHibernate.Dialects on a different release cycle? On Mar 4, 2013 4:55 AM, "Richard (gmail)" <[email protected]> wrote: > FWIW, I agree with Oskar and Patrick on this. > > I think administrative overhead of having separate projects is a large > cost for a relatively small benefit of moving the dialects/drivers out of > NHibernate. > > In addition, there is nothing to stop someone creating a separate > driver/dialect on a case-by-case basis. If the community started to favour > it over the in-built one, then I'm sure the changes would be incorporated > into the core at that point. > > > -----Original Message----- From: Oskar Berggren > Sent: Monday, March 04, 2013 7:57 AM > To: > nhibernate-development@**googlegroups.com<[email protected]> > Subject: Re: [nhibernate-development] Move Dialect/Drivers outside of the > core. > > 2013/3/4 Alexander I. Zaytsev <[email protected]>: > >> Hi Patrick >> >> 1. I think that ability to make own small package instead of building own >> NHibernate is an advantage. As for now many dialects/providers are outdate >> or have minor or even trivial errors, and people often wait years to have >> these issues to be fixed. Also there are number of independent providers >> > > From time to time there are small but importand fixes everywhere. As > an alternative to this, I'm thinking we should try to increase the > pace of minor releases. With the stable assembly version we know have > I think this can be done, if only we decide that's what we want (the > 3.3.3 cycle is way longer than I would have preferred). If we agree > that we want shorter cycles, to make it happen we should probably aim > for a release every two months. With such a time frame we should be > able to maintain each release to a manageable set of changes > (acceptable risk). > > As someone mentioned, I too fear the risk of increased maintenance > burden of having to handle multiple repo's. The situation with the > existing contrib modules isn't encouraging. > > /Oskar > > -- > > --- You received this message because you are subscribed to the Google > Groups "nhibernate-development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to > nhibernate-development+**[email protected]<nhibernate-development%[email protected]> > . > For more options, visit > https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> > . > > > -- > > --- You received this message because you are subscribed to the Google > Groups "nhibernate-development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to > nhibernate-development+**[email protected]<nhibernate-development%[email protected]> > . > For more options, visit > https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> > . > > > -- --- You received this message because you are subscribed to the Google Groups "nhibernate-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
