What mean "NHibernate.Databases.PostgreSQL" ? On Mon, Mar 14, 2011 at 12:35 PM, Patrick Earl <[email protected]> wrote:
> I'm certainly in support of having a separate NHibernate.Core package. > I don't think it's necessary for every contrib package to reference > everything needed to get up and running. I think NHibernate users > aren't typically going to start with the idea that "I want this one > add-on", but will instead likely use NHibernate first and add things > on from there. If you consider people that are running different > databases, the necessity of multi-step installation seems more clear. > For example, to get a bare package running for PostgreSQL, you'd need > something like: > > NHiberante.Core > NHibernate.ByteCode.Castle > NHibernate.Databases.PostgreSQL > > We would actually want NHibernate.ByteCode.Castle to do some > configuration and set up the proxy factory factory setting for us. If > you had LinFu installed, and then were forced to install > NHibernate(+castle) because of a dependency, it might change your > LinFu proxy settings to Castle proxy settings. > > Note that I changed the name of Castle, to ByteCode.Castle. If we > classify them into groups, it may become more clear how to use them. > For example, imagine we have this list: > > NHibernate.Core > NHibernate.ByteCode.Castle > NHibernate.ByteCode.LinFu > NHibernate.ByteCode.Spring > NHibernate.Database.MsSql2008 (adds appropriate connection strings and > standard properties to user's config file) > NHibernate.Database.PostgreSQL > NHibernate.Database.SQLite > > Any sort of introductory docs could simply state that the user needs > to select one of each... one ByteCode, one Database. At the very > least, when the user searches for NHibernate, they'll wonder what > these "ByteCode" and "Database" categories are, and that might prompt > them to read the description, letting them know what they need to > install. I actually think it's fair to use the descriptions of these > packages to convey information on requirements in our scenario. > Granted, you might still end up with a user just installing > "NHibernate" by name. > > Here's a new idea. Make NHibernate a dummy package that isn't > actually needed for anything. All you would get is a file explaining > what other packages you need to install. Then there's no possibility > of people depending on the wrong packages. If needed though, I > generally support the use of castle as the default proxy provider. > > I think it's important that the packages come with configuration. > It's not generally the assemblies themselves that are the hard part of > getting NH running, but the associated config. Once the user has > selected their two packages, they should only really need to change > the example connection string in the config and start writing some > code. > > Patrick Earl > > On Mon, Mar 14, 2011 at 8:15 AM, Stephen Bohlen <[email protected]> wrote: > > The intent was that Nhibernate.Core would be available for other package > > authors to reference in cases where they wanted fine-grained control over > > the 'composition' of their packages. > > > > The canonical example I had in mind when thinking this scenario out was > that > > of Castle's ActiveRecord. It would (conceivably) be possible for the > Castle > > ActiveRecord package to depend directly on Nhibernate.Castle (or, if > Castle > > is to be the 'default', then on just the 'Nhibernate' package). But if > the > > Castle.ActiveRecord package were to take this dependency in this manner > then > > they would be at the mercy of the version of Castle that is specified in > OUR > > packages rather than being able to state their version requirements for > > themselves. > > > > so... > > > > Castle.ActiveRecord > > --> Castle.Nhibernate > > > > ...or... > > > > Castle.ActiveRecord > > --> Nhibernate > > > > ...would force them to 'accept' the version constraints for Castle.Core > that > > *we* define in the NH packages. > > > > But... > > > > Castle.ActiveRecord > > --> Nhibernate.Core > > --> Castle.Core > > > > ...would permit them to state their dependency on NH with whatever > version > > constraints they wanted to enforce in their own packages. > > > > Its possible that this scenario is just an edge case and I (honestly) > have > > trouble suggesting another use-case than just Castle.ActiveRecord so > maybe > > this is over-thinking the problem and introducing unnecessary complexity. > > > > On the other hand, I wonder if its the case that a hypothetical future > > Nhibernate.Caches.MemCacheD package needs a dependency on 'Nhibernate' > (with > > the default proxyfactoryfactory) rather than just on Nhibernate.Core. > Maybe > > you're right that the dependency for *all* nhcontrib-style packages would > be > > best-stated in terms of nh-with-the-default-proxy, but if so then suppose > > I've done the following: > > > > added Nhibernate.Linfu package b/c I *know* that's what I want > > add the Nhibernate.Caches.MemCacheD package b/c I want to use 2nd level > > caching > > > > When I get to step #2, this will (needlessly) bring in Nhibernate (with > > default proxyproxyfactory) which in turn (as suggested earlier) will > > probably 'pass-thru' to bring in the Nhibernate.Castle package > > unnecessarily. AFAIK NuGet doesn't let you state dependencies as "at > least > > one of the following must be present: Nhibernate.Castle, > Nhibernate.LinFu, > > or Nhibernate.Spring..." (which is sort of how I would think it would be > > best for the nhcontrib-style packages to state their dependencies). > > > > What do you (and others) think is the best way to address this --? If we > > think it best for these to take dependencies on just 'Nhiberate' (w. > default > > proxyproxyfactory) and we consider the Castle.ActiveRecord scenario to be > an > > unsupportable edge case then maybe Nhibernate.Core *can* just go away.... > > > > Steve Bohlen > > [email protected] > > http://blog.unhandled-exceptions.com > > http://twitter.com/sbohlen > -- Fabio Maulo
