I totally understand and support this philosophy. What I'm looking for is justification to designate NHibernate Spatial as a separate project. Consider the other NHibernate Contrib projects:
Hbm2Net - obvious separate tool, easily distinguishable from NHibernate NHibernate Validator - allows you to basically specify code contracts, easily separable NHibernate Caches - caching framework that works with NHibernate NHibernate Mapping Attributes - "**alternative** way for mapping entities" NHibernate Linq - moved into NH core! NHibernate Burrow - also obviously separate, its a provider of session state for ASP.NET NHibernate ProxyGenerators - independent tool that produces output useful for NHibernate With the exception of NHibernate Linq, each one of these contrib projects are easily separable from NHibernate and provide an ancillary ability. That isn't the case for Linq, and the new Linq provider is in the core now! Most popular database engines - MySQL, SQL Server, Oracle, Postgresql, and now even Sybase are providing *native* Spatial functionalty as first-class data types in the database. Why does NHibernate treat it like second class data? Why is the mapping for a data type such as, say, bool or int built into NHibernate core, but OGC geometry data (a native, built-in data type to many of these database engines) is relegated to a separate project? There may be good reasons, but the only reason that I was given is basically "it is a good idea, and it was a great decision." Why is it a great idea? One of the things you mentioned is that it causes the project maintainers to have to keep the code up to date, not the core team. The same argument could apply to creating an "NHibernate Boolean" project, moving all support for booleans out of the core, and then saying "Its up to the NHibernate Boolean project to ensure booleans are supported when we make core changes." To work based on your philosophy of doing things right, not doing them fast, it would make sense to me that just because spatial data isn't nearly as widely used as other data types, it still should receive the same first-class support that the database engines are providing it. *I want to contribute to the spatial stuff either way.* However, before I do so I want to make sure I'm not about to spend a large amount of time providing extensibility into the Linq provider if it makes no sense to put NHibernate Spatial in a separate project. Can we at least have the open dialog about whether it is makes sense for spatial code to remain separate or if merging it into the core would be more appropriate? Thanks, David On Sat, Apr 24, 2010 at 10:17 AM, Fabio Maulo <[email protected]> wrote: > Ok... I must explain this : "For easy things you have your real-world work > " > In real-world the most important is: money, money, money. > The main rule in your work is : business target first! > > In OSS what is important is: do the right thing applying the best pattern > you know. > Here we must do our best with: program-to-interface not to > implementation, IoC, DI, uncoupling etc. etc. > Here the "time" is not important. > > One of my usual answer in OSS is : "take your time and do your best". > > On Sat, Apr 24, 2010 at 10:23 AM, Fabio Maulo <[email protected]>wrote: > >> this is not an easy world. For easy things you have your real-world work. >> >> Having those projects outside the trunk is perhaps the best decision we >> ever taken. >> Maintain it aligned to the core-trunk is a task of that specific project >> team and not an additional task for core-team. >> >> You are worried only for Spatial but Spatial is simply the less used >> project in contrib; >> what about NHCH, NHLQ, NHV, NHSR, NHB, NHMA ? >> >> If you think that you need to have a reference to Spatial inside the core >> we are fried. Perhaps you will need an extension point where it isn't there >> so far. >> >> Steve, >> How we are managing custom-function in the new Linq-provider ? >> >> >> On Sat, Apr 24, 2010 at 10:01 AM, David Pfeffer <[email protected]>wrote: >> >>> I am definitely interested. I'm just confused as to why put it in >>> Contrib? Any breaking changes in the NH trunk would have to be fixed in >>> Contrib, and you're going to always have the mismatch between Contrib and NH >>> trunk. Also you have the awkwardness of having to use Spatial dialects, >>> which means you can't use any other library that requires its own dialect. >>> >>> For example, its going to be very difficult to support Linq in Spatial >>> without being able to directly reference spatial from the Linq provider, >>> which is now in NH itself. Linq as I'm sure you know converts the user's >>> input into an expression tree, and the expression tree walker would need >>> awareness of Spatial in order to know that calling, say, .STIntersects on a >>> GeoAPI object should correlate to a certain sort of query. Spatial doesn't >>> seem to be enough of a "separate project" to be put in NHContrib, if you >>> want it to work as well as NHibernate itself does. >>> >>> >>> On Sat, Apr 24, 2010 at 8:52 AM, Fabio Maulo <[email protected]>wrote: >>> >>>> Spatial, as others prjs are part of Contrib and will be part of Contrib. >>>> Perhaps it was one of the best decisions took some years ago. >>>> If you are really interested in develop it and maintain it multi-RDBMS, >>>> let us know. >>>> >>>> On Fri, Apr 23, 2010 at 9:46 PM, David Pfeffer <[email protected]>wrote: >>>> >>>>> Who is working on NHibernate Spatial? It appears to have been dormant >>>>> for nearly 9 months now. >>>>> Why is NHibernate Spatial not part of NHibernate itself, but instead >>>>> part of NHContrib? >>>>> >>>>> I'd be happy to take over working on NHibernate Spatial if it has been >>>>> dropped or contribute substantial assistance if there is someone still >>>>> actively maintaining it. There's a lot of work left to do, and I'm >>>>> using NHibernate Spatial extensively in a project that currently has >>>>> an indefinite ending (-- for a startup company, so either it will die >>>>> in a year or two or else I'll be doing this for a very long time). For >>>>> example, I'd like to see LINQ support for spatial as well as proper >>>>> support for the SQL Server coordinate ordering format. (The latter >>>>> being a huge pain point for me.) >>>>> >>>>> I haven't worked on large open source project in about 5 years now, >>>>> but the last time I did I found it to be very rewarding. Considering >>>>> in this instance it makes a lot of sense for my start-up for me to >>>>> actively see NHibernate Spatial get developed, and it could be fun, it >>>>> seems win-win. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>> -- >>>>> Subscription settings: >>>>> http://groups.google.com/group/nhibernate-development/subscribe?hl=en >>>>> >>>> >>>> >>>> >>>> -- >>>> Fabio Maulo >>>> >>>> >>> >> >> >> -- >> Fabio Maulo >> >> > > > -- > Fabio Maulo > >
