NHibernate Configuration

[Tuna Toksöz]

Hello,

I see that Fluent NHibernate produces xml in order to configure session factory.

I know that it is not possible to do otherwise, since configuration api is bound to xml. I don't like that and as an NHibernate committer, I can extend the configuration api as needed.

What do you guys think? We are willing not to duplicate effortts, as we wanted to implement NHibernate Fluent Mapping on our own, but it is better to not to duplicate.

Thanks!

--
Tuna Toksöz

Typos included to enhance the readers attention!

[Jeremy D. Miller]

Tuna,

Personally, I think that would be an awesome idea.  *I'm* the one responsible for the Fluent NH generating the Xml and I always considered it a temporary hack.  Here's another thought for the group.  Let's say that we do use the real metadata model and that we can get programmatic access to this internal model.  I'd like to re-purpose that information in the NH model to generate some screen synchronization code in our MVC architecture.

I'm not a fan of the Entity Framework approach at all, but using the EDM as a way to ease data replication.  What if you could read over the NH metadata and dump an EDM out the back for replication and whatever other value the EDM provides (assuming that there is any other value)?

 

Jeremy D. Miller
The Shade Tree Developer
jeremy...@yahoo.com

[Chad Myers]

Tuna,

 

Yes, we’d very much like to discuss this.  It should be noted that I approached the NHibernate developer’s mailing list about this and it was almost unanimously rejected due to the fact that it could inject instability into one of the more stable parts of NHibernate (configuration).

 

If the developers are willing to re-evaluate this decision, that is good news indeed!

 

Thanks,

Chad

[Dru Sellers]

+100000 with access to the NH metadata

oooo...ooo... (drool)

mmmm. doughnuts

yum yum yum

-d

[James Gregory]

I definitely think this is a great idea. As Chad said though, I was
under the impression that this wasn't a desirable addition to nhib
core.

On 11/5/08, Dru Sellers <d...@drusellers.com> wrote:
> +100000 with access to the NH metadata
>
> oooo...ooo... (drool)
>
> mmmm. doughnuts
>
> yum yum yum
>
> -d
>
> On Wed, Nov 5, 2008 at 11:23 AM, Chad Myers <ch...@chadmyers.com> wrote:
>
>> Tuna,
>>
>>
>>
>> Yes, we'd very much like to discuss this. It should be noted that I
>> approached the NHibernate developer's mailing list about this and it was
>> almost unanimously rejected due to the fact that it could inject
>> instability
>> into one of the more stable parts of NHibernate (configuration).
>>
>>
>>
>> If the developers are willing to re-evaluate this decision, that is good
>> news indeed!
>>
>>
>>
>> Thanks,
>>
>> Chad
>>
>>
>>

>> *From:* fluent-n...@googlegroups.com [mailto:
>> fluent-n...@googlegroups.com] *On Behalf Of *Tuna Toksöz
>> *Sent:* Wednesday, November 05, 2008 10:11 AM
>> *To:* fluent-n...@googlegroups.com
>> *Subject:* [fluent-nhib] NHibernate Configuration

[Tuna Toksöz]

Yes, i will try to extend the points such that they won't inject instability. It should be noted that it's only an idea now, which may not come into reality.

I am in touch with the rest of the committers of NH about this issue and they told me to send mail to this group, to see what we can do. Maybe for now, we will work on a seperate branch and if it is stable enough, merge it to trunk.

I have no problems with HBM but i see a great value behind this configuration thing. It will enable easier fluent interface support and even DSLs!

Let's keep in touch, and tell me what you need.

[Chad Myers]

Tuna,

 

I’m very excited about this, so I hope it works out in the end.

 

When I was doing some explorations to see if this was feasible, I found that the logic to populate the mapping model stuff was extremely XML-based to the point where you couldn’t tell who was setting what property where since there were many levels of nesting.

 

At various points in the code, it would just read a magic attribute from the XML and set a property on the model. It seemed like a lot of magic was going on.

 

I’m sure there are lots of tests, but I would think that the first place to start might be to fully understand all the possible options available from the XML and how and where those get mapped to the model because, today, it’s all over the place.

 

I think that this is what the project leads were most concerned about.  I think we can beat it with lots of test coverage, though.

 

-c

[Oğuz Kurumlu]

The fluent api depends to xml. Required a lot of change for this. We will so happy when the merging is finished :)

[Fabio Maulo]

Hi.
If you can see the history in nh-dev-list you can find some post about
"mapping source".
You don't need to create xml to mapping NH because Xml is only the
default "mapping source".
As I said you, in chat, the configuration have a public method
CreateMappings. The Mappings class, probably, have all you need to
inject all metadata before Build the session factory and the
NHibernate.Configuration class can be inherited and extended or
overridden (note: the Mappings class instance is the class used by all
xmlBinders for all hbm files).

BTW, IMO, the next step is not create another "common" mapping source
but create something to avoid mappings all as possible.
For example in an inherited Configuration class you can add a method
as
Register<T>() where T: class
the method can use CreateMappings to add all metaInfo of the class.
You can use convention over configuration for all most common entinty.
Another possible extension is Register<T>(IMappingDefault defaults).
Each implementation of IMappingDefault may include:
- all actual default config
- default id mapping (name + generator + etc)
- entity-name strategy (it will be very important to support generics
entities mapping)
- default length for strings
- default precision for decimal, double etc.
- default conf for IList (list, bag, id-bag etc.)
- default conf for aggregation association (many-to-one, one-to-many)
- strategy for fieldnames
- strategy for tablename
- default tuplizers
- etc. etc.
In practice after a Register<T>(IMappingDefault defaults) what you
really need is configure only the difference from a default.
Inheriting from NHibernate.Configuration you can even mix the "new
way" with the "Xml way".

What I would like to have in the future is: NHibernate.ORuM (Object
Relational unMapping)

To do it I'm pretty sure that you don't need to change existing APIs.

Bye.
Fabio Maulo.

[Paul Batum]

I had no idea that IMappingDefault existed. Would not this be a much better alternative to our current approach regarding conventions?

[Fabio Maulo]

On 9 nov, 06:19, "Paul Batum" <paul.ba...@gmail.com> wrote:
> I had no idea that IMappingDefault existed. Would not this be a much better
> alternative to our current approach regarding conventions?

It not exists.
The problem of "conventions" is : have something to define which is
the convention you want use.

[Paul Batum]

Ahh, I'm sorry Fabio, I misread your post. So are you suggesting that perhaps NHibernate should incorporate some conventions style functionality, including some sort of IMappingDefault interface?

[Fabio Maulo]

Not NH but the FW to avoid XMLs mappings or avoid mappings at all.

On 11 nov, 11:49, "Paul Batum" <paul.ba...@gmail.com> wrote:
> Ahh, I'm sorry Fabio, I misread your post. So are you suggesting that
> perhaps NHibernate should incorporate some conventions style functionality,
> including some sort of IMappingDefault interface?
>

[Paul Batum]

So can I just ask for some clarification because there seemed to be
conflicting answers... does the NHibernate trunk offer a configuration
capability that looks like a viable alternative for us, instead of
generating hbm xml? I would love to move away from generating xml BUT
the vast majority of our unit tests assume we are generating xml! If
we intend to change the mechanism we use to supply nhibernate with
mappings at some point down the track, shouldn't we be worried about
all those xml dependent unit tests?

[James Gregory]

We'd just have to rewrite the tests! :)

[Paul Batum]

Yes, but it means its a really significant rewrite, basically a redevelopment. We'd end up keeping the public API, and little else, and it would all have to happen in one go.

[James Gregory]

Indeed, but if it means no more XML then I don't see the problem. It's all still up in the air yet anyway, so I don't think there's reason to be concerned yet.

[Paul Batum]

Well the point I was eluding to is that there might be a better way for us to approach our implementation and unit tests today, given that we would all love to give XML the boot.

Imagine for a moment that someone creates a fork of NHibernate that uses a different format for describing mappings, and this fork becomes very popular and that we want to support it. One route I can imagine us going down is developing our own model for representing NHibernate mappings, and then implementing two mapping writers, one for each of the mapping formats. Basically this approach is about removing the Write() method from OneToManyPart and its ilk.

Now if we started down this route today, we could write unit tests that confirm that the public api generates the correct model, and then if we ever ditched xml, those unit tests would stay. Thinking about it a little more, I suspect we wouldn't want to ditch xml completely - we would probably want to support xml AND whatever else nhibernate is prepared to accept.

One could also make the argument that the proposed approach is just better in terms of seperation of concerns, and shoud be done anyway, even if the XML is here to stay.

Thoughts?

Paul Batum

[Ayende Rahien]

One of the reasons NOT to use XML is performance.

NH has to do schema validation on the XML, and that is EXPENSIVE!

[David Mukaiwa]

I've always wanted the ability to configure a sessionfactory without involving xml but the metamodel seemed to be too far beneath the surface for me to use comfortably. Most of the documentation I've read also makes no mention of it. I like the direction proposed by this discussion and I think a world of good will come out of it. Fabio's convention over configuration suggestion would push NH closer to becoming the 'silver bullet' that some fantasize ORM to be. A bit like Fabio's AutomatedDeveloper.

[Tuna Toksöz]

Exactly my thinking. it takes so much time to validate and parsing!

On Thu, Nov 13, 2008 at 3:15 PM, Ayende Rahien <aye...@ayende.com> wrote:

[Fabio Maulo]

well... configure the session factory is a joke... really.
Create your implementation of IHibernateConfiguration, inherit from
Configuration and then use DoConfigure(IHibernateConfiguration hc).

About "AutomatedDeveloper": somebody, someday, may see the light.

On 13 nov, 10:32, "David Mukaiwa" <dmuka...@gmail.com> wrote:
> I've always wanted the ability to configure a sessionfactory without
> involving xml but the metamodel seemed to be too far beneath the surface for
> me to use comfortably. Most of the documentation I've read also makes no
> mention of it. I like the direction proposed by this discussion and I think
> a world of good will come out of it. Fabio's convention over configuration
> suggestion would push NH closer to becoming the 'silver bullet' that some
> fantasize ORM to be. A bit like Fabio's AutomatedDeveloper.
>
> On Thu, Nov 13, 2008 at 3:15 PM, Ayende Rahien <aye...@ayende.com> wrote:

> > One of the reasons NOT to use XML is performance.NH has to do schema

> > validation on the XML, and that is EXPENSIVE!
>

> > On Thu, Nov 13, 2008 at 3:13 PM, Paul Batum <paul.ba...@gmail.com> wrote:
>
> >> Well the point I was eluding to is that there might be a better way for us
> >> to approach our implementation and unit tests today, given that we would all
> >> love to give XML the boot.
>
> >> Imagine for a moment that someone creates a fork of NHibernate that uses a
> >> different format for describing mappings, and this fork becomes very popular
> >> and that we want to support it. One route I can imagine us going down is
> >> developing our own model for representing NHibernate mappings, and then
> >> implementing two mapping writers, one for each of the mapping formats.
> >> Basically this approach is about removing the Write() method from
> >> OneToManyPart and its ilk.
>
> >> Now if we started down this route today, we could write unit tests that
> >> confirm that the public api generates the correct model, and then if we ever
> >> ditched xml, those unit tests would stay. Thinking about it a little more, I
> >> suspect we wouldn't want to ditch xml completely - we would probably want to
> >> support xml AND whatever else nhibernate is prepared to accept.
>
> >> One could also make the argument that the proposed approach is just better
> >> in terms of seperation of concerns, and shoud be done anyway, even if the
> >> XML is here to stay.
>
> >> Thoughts?
>
> >> Paul Batum
>

> >>  On Thu, Nov 13, 2008 at 9:35 PM, James Gregory <jagregory....@gmail.com>wrote:
>
> >>> Indeed, but if it means no more XML then I don't see the problem. It's
> >>> all still up in the air yet anyway, so I don't think there's reason to be
> >>> concerned yet.
>

> >>> On Thu, Nov 13, 2008 at 9:31 AM, Paul Batum <paul.ba...@gmail.com>wrote:
>
> >>>> Yes, but it means its a really significant rewrite, basically a
> >>>> redevelopment. We'd end up keeping the public API, and little else, and it
> >>>> would all have to happen in one go.
>

> >>>> On Thu, Nov 13, 2008 at 3:57 AM, James Gregory <jagregory....@gmail.com

> >>>> > wrote:
>
> >>>>> We'd just have to rewrite the tests! :)
>

> >>>>> On Wed, Nov 12, 2008 at 1:53 PM, Paul Batum <paul.ba...@gmail.com>wrote:
>
> >>>>>> So can I just ask for some clarification because there seemed to be
> >>>>>> conflicting answers... does the NHibernate trunk offer a configuration
> >>>>>> capability that looks like a viable alternative for us, instead of
> >>>>>> generating hbm xml? I would love to move away from generating xml BUT
> >>>>>> the vast majority of our unit tests assume we are generating xml! If
> >>>>>> we intend to change the mechanism we use to supply nhibernate with
> >>>>>> mappings at some point down the track, shouldn't we be worried about
> >>>>>> all those xml dependent unit tests?
>

> >>>>>> On Wed, Nov 12, 2008 at 5:03 AM, Fabio Maulo <fabioma...@gmail.com>

[Tuna Toksöz]

BTW, I really liked how Fluent NH was written, and learnt lots of things from it, thank you guys.

I started to rewrite fluent nh with nh metadata, to see how it goes. I made 46 tests pass(modifications to tests have been made, obviously) in FluentNHibernate.Testing.DomainModel.Mapping around in 2 hours.
I now have a few hundreds more.

Let's see how it goes.

--
Tuna Toksöz
http://tunatoksoz.com

[Paul Batum]

Hi Tuna,

Sounds like we are both attempting something similar. I was wondering if you have posted anything about your approach or if the code is public anywhere yet? Depending on how similar our directions are, it might be more useful for us to collaborate rather that both go our separate ways.

This post contains links to the information I've published so far regarding my effort:
http://groups.google.com/group/fluent-nhibernate/browse_thread/thread/bd4b735ff3872491/fc2a04b2b31dc859

But to summarise, my current approach uses the Hbm* classes from NHibernate.Cfg.MappingSchema. I got it to the point where some really basic mappings were working properly, but I'm not exactly happy with the Hbm approach. You say you are using "nhibernate metadata" - can you be more specific?

Thanks!

Paul Batum

[Tuna Toksöz]

I don't have anything public yet but the entry point for me was Fabios post: http://fabiomaulo.blogspot.com/2008/11/mapping-source-how-map-class-without.html

For now, I am trying to make it just work,using existing classes (but without xml).

Hope his post helps to show what i have.

On Sat, Dec 13, 2008 at 1:29 AM, Paul Batum <paul....@gmail.com> wrote:

But to summarise, my current approach uses the Hbm* classes from NHibernate.Cfg.MappingSchema. I got it to the point where some really basic mappings were working properly, but I'm not exactly happy with the Hbm approach. You say you are using "nhibernate metadata" - can you be more specific?

[Tuna Toksöz]

And I should have missed your linked post, probably because we had national holiday here in Turkey.

One advantage of HBM over my approach is that Configuration api may change in someway, but hbm is likely to stay the same.

Thanks!

On Sat, Dec 13, 2008 at 1:29 AM, Paul Batum <paul....@gmail.com> wrote:

[Paul Batum]

Tuna,

I think your approach will be better. Taking a second look at Fabio's
post, I think I should have paid more attention to it the first time I
was linked. An option that does not include any XML at all has more
chance of succeeding, in my opinion.

Hmm, where to go from here? Somehow I suspect that Chad and Jeremy did
not have the NHibernate.Mapping classes in mind when they both
described the idea of rebuilding fluent nhibernate to work off a
semantic model. So what are they after?

I still have 3 weeks before I resume full time work and I would like
to put them to good use but I'm really not sure which direction to go
now.

Paul Batum

[Tuna Toksöz]

Paul,

Well, we can collaborate if you wish. What I have is not yet working and it has quick and dirt coding, but what i had in mind is to have something working and then refactor.
We can think on a better design(instead of quick&dirty then refactor)

Regards.

[Chad Myers]

Paul, Tuna:

Tuna's approach is, I believe what ultimately needs to happen. The reason I disagreed with this approach when Fabio suggested it is that there is tons of logic and special functioanlity inside the XML mapping reader/binding code inside NHibernate. Without good test coverage over all those cases, we'll be essentially rewriting nhibernate maping in the dark and many problems and incompatibilities will surface. Ultimately, we want to end up with Fabio/Tuna's approach, but I think its much riskier in the short term due to the amount of logic and the lack of tests (on our end).

I know NHib has lots of tests that we could leverage, but I'm guessing they're mostly XML based which would require porting to our new system. Also, I'm afraid that the NHib mapping tests don't have 100% coverage which would mean we'd have to fill in gaps.

I think that the best solution is for NHib's mapping system to use a semantic model that can be fed by XML, Fluent NHib, or anything else. The logic involved in mapping would be contained here so all mapping sources obey by the same fundamental rules and expectations of the NHib engine.

Tuna's approach could essentially become this, but it is a major undertaking to do it right and preserve all the functionality and not introduce a bunch of new problems. This is why I shy'd away from it at first.

In the short term, something needs to be done with FluentNHibernate to allow more complex functionality andthis is why I like Pauls approach as it gets us out of the streaming XML generation mode and into model-based logic which is much easier to write and test. That model can then be serialized to HBM or used for various other purposes.

Perhaps we should be working from both sides: helping Fabio by improving the mapping subsystem while weaning Fluent NHib off of XML. Eventually, we can meet in the middle and have an adapter that goes from Fluent NHib's internal model to NHib's mapping model?




----------------------
Sent from my phone. Please excuse typos and extra characters

-----Original Message-----
From: Paul Batum <paul....@gmail.com>
Sent: Saturday, December 13, 2008 4:00 AM
To: fluent-n...@googlegroups.com <fluent-n...@googlegroups.com>
Subject: [fluent-nhib] Re: NHibernate Configuration

[Chad Myers]

Maybe if we did a little analysis first to discover how broad the coverage is of NHib's mapping system and use those and fill in gaps. Then we can start off small with Tuna and Paulbs code and just tart working to make tests pass? This is good because then we'll have a real clear goal and it'll be easy for people to pick up tests, make 'em pass, and submit patches.

----------------------
Sent from my phone. Please excuse typos and extra characters

-----Original Message-----
From: Tuna Toksöz <teh...@gmail.com>
Sent: Saturday, December 13, 2008 4:11 AM
To: fluent-n...@googlegroups.com <fluent-n...@googlegroups.com>
Subject: [fluent-nhib] Re: NHibernate Configuration

Paul,

Well, we can collaborate if you wish. What I have is not yet working and it
has quick and dirt coding, but what i had in mind is to have something
working and then refactor.
We can think on a better design(instead of quick&dirty then refactor)

Regards.

[Chris Marisic]

If there's anyway I can help you guys out with this or anything else
on FH I'd be more than glad to help.

[Tuna Toksöz]

+1 I am upto it. I worked a little bit more on my local trunk and definitely we need some analysis.
Maybe you guys add me as committer and me and Paul(and whoever upto it) work on a branch? I plan to concentrate on this next month, but i think i can contribute until that time.

[Tuna Toksöz]

Hey! James was kind enough to add me as a committer! Thanks!
I hope to concentrate on this soon.

[Paul Batum]

Hi Chris,

It would be great if you could take a look at some of the issues in
the issue list.

In particular, these issues could benefit from your attention:
54, 59, 63, 65, 74, 83

Cheers!

Paul Batum

[Paul Batum]

I'm keen to see how you've approached it Tuna. Let me know when you've
checked in your branch!