Wilson ORM extensions vs a New Project

[Fregas]

Hi all,

Its rather quiet here and I haven't seen any updates on google code.

I was thinking about creating my own ORM and Object Server, but having
worked with both NH and Wilson, it seemed silly to start from scratch.
I have considered taking the Wilson ORM and using as a basis for my
own, but doing so would dramatically change the ORM where its no
longer recognizable as Wilson. Specifically I'd like to make the
following changes:

To Add:
POCO / PI support
Linq support
WCF support so that objects can be retrieve/populated w/ data via a
WCF service, for desktop apps and smart clients.
Dictionary, enum, components like NH
OneToOne relationships
More Cascade Update/Delete options
Fluent Mappings like NHibernate Fluent Interface

Remove:
Mappings via xml (maybe)
Object Helper and OPath
Object Holder and instead use Proxies or something for lazy load

This is all just pipe dreams right now. But I wondered if there were
any licensing issues with forking a new project off of Wilson or if
the community would rather see these changes be rolled into the
current Wilson ORM, despite the fact it would break a lot of backwards
compatibility and change the ORM quite a bit. The wilson codebase and
api is much cleaner than NH, so it seemed like a good place to start.

Thanks,
Craig

[shovavnik]

If you preserve backwards compatibility for configuration (e.g., xml
mappings) and querying (e.g., OPath), I'd recommend continuing the
current project.

But if you plan to break backwards compatibility significantly (as it
sounds), even if the changes are worthwhile and overdue, I think a
fork is in order.

I don't know about the licensing issues; haven't looked into it.

shovavnik

[Fregas]

I definitely plan on breaking backwards compatibility. OPath seems
dated compared to Linq. The xml mappings I may decide to keep and
just give both options. Wilson's source code has a nice object model
that will make this easier.

Does anyone know what license this uses?

Craig

[Travis]

I'd kinda confused as to why you would want to do this.  Why not just use a well established baked in product like NHibernate?  What is NH lacking that would cause someone to do anything like this?

[Fregas]

We actually use NHibernate here at work, and there's a lot I like
about it. But it has some issues:

1) The api is showing its age. A lot of stuff is deprecated or
inconsistent. There's a lot of leftovers from the java version I
think.
2) The Linq and Fluent Interface stuff are seperate projects in
seperate downloads.
3) Bidirectional mappings are a pain to set up and require changes to
your domain layer.
4) The mappings aren't very clear. Setting up a one-to-one is a pain
if you don't know what you're doing. lazy load isn't available in all
situations. There's (IMHO) an unnecessary number of seperate tags you
have to learn to do bags, sets, components, etc.
5) HQL is incomplete. Some things work, and some don't.
6) Lots of little developer surprises. For example, if you have a
many-to-one relationship, when NH saves your object, it saves its many-
to-one foreign key as null, then goes back and performs an update
statement to fill it. This wreaks havoc on NOT NULL constraints.
7) Using NHibernate in a tiered environment like a smart client is
difficult, especially with lazy-load enabled. If you want to
serialize your objects using WCF or old fashioned remoting and pull
them down over the wire, NH tries to lazy load every property. If you
turn off lazy loading, it prefetches everything.

In general, just a big learning curve. I think we can do better, and
EF isn't out yet and isn't very mature. Its not that I think i'm some
badass developer, but that i've seen a lot of the strengths and
weakneses in all the mappers.

NHibernate is a good product, but it will be replaced someone,
somewhere, its just a matter of when.

Craig

[Brian DeMarzo]

Although I agree with the NHibernate issues (i spent a good chunk of today getting NH with NH.Search and NH.Linq running - it can be done but it takes time), I wonder if a whole new ORM is sensible. Considering the breadth of hours required to build one, couldn't that time be spent improving the issues with NH?

Afrer all, NH does a lot already. Granted it suffers from sync issues between the trunk and the contribs, and it is not without pains. That being said, Apache/Mysql/Php on Windows ("WAMP") was historically a bear to implement, until some folks came up with packages that are in sync. Can't the same be done with NH - put together the core, Linq, Fluent, and other interesting bits in a single distribution that are built on the same base to ease people's pain?

Personally I have moved on to NH in new projects, though WORM (and my fine wrappers) still serve projects well. Maybe add CodeSmith templates and a wrapper with a streamlined NH distro?

- brian

I do agree with the merits of WORM - it truly is the easiest of the bunch. That being said, the effort to bring it to the modern era is significant.

[Fregas]

I have looked at the NHibernate source code, and it is a beast. I
think starting with something simpler, with a clean codebase, without
any java conversion idiosyncrasies and without worrying about
backwards compatibility might be easier than trying to fix Nhbernate.
I have a feeling that the reason NHIbernate acts flaky at times is
because the code-base is such a mess. The NH team hasn't cleaned
things up because their code is brittle and difficult to work with.
Thats why i've been looking at WORM. The other main difference in how
I would develop a new ORM is by using TDD. I would have unit and/or
integration tests for everything, to ensure old functionality doesn't
break and to keep the codebase clean. I think something as critical
and essential to your application as an O/R Mapper should be built on
TDD. NHibernate isn't built that way, as far as I know. I could be
wrong.

Granted the time to get WORM up to speed is not trivial. I'm still
trying to decide if

a) I even want to do it
b) I want to open source it or eventually commercialize it
c) If there would be any licensing issues.

There are already efforts out there to make NHibernate easier to deal
with, such as Castle's ActiveRecord. But even with those you have to
deal with HQL not working correctly, or surprises within the
mappings. For me it was easier to use NHibernate directly than to use
Castle, because there was one less leaky abstraction to learn and deal
with. I do think having a distribution with Linq and Fluent built in
would be great though. I'm not sure about the codesmith thing. I've
built my own codesmith templates to work with NH, but its hard to do
Domain Driven Design with database driven code generation. So for
larger projects, I do without codesmith and roll my objects and
mappings by hand.

Craig

[Brian DeMarzo]

I have NH binaries all based on 2.0.1 GA that includes the NH core plus NH.search, FluentNH, and NH.linq. Works fine too (project it is in unit tests with all of the above), though there was limited LINQ and Lucene testing (just simple queries).

I agree that TDD is mandatory. NH has pretty good test coverage, as does Castle. I have used NH, Castle, and WORM in production and never had ongoing issues... Though maybe I was lucky. :)

you hit the nail on the head when you said, "Do I want to do it?" There is no point starting a new ORM if you don't expect to finish, unless it is as an experiment. it's a huge task.

That being said i'd lean towards encouraging you to enhance WORM (already a stable, working ORM that seems to have the cleanliness you desire). I believe WORM is now under a modified MIT license - the license is in the source header and on the Google Code project.

- b