Mapping source

[Fabio Maulo]

As promised
http://fabiomaulo.blogspot.com/2008/11/mapping-source-how-map-class-without.html

Possible since NH2.0.0Apla1 even if I'm using NH2.1 in that example.

Bye.
Fabio Maulo.

[Tuna Toksöz]

Which looks promising :) I think Fluent NHib guys can make use of it very well.

--
Tuna Toksöz

Typos included to enhance the readers attention!

[Chad Myers]

Fabio, thank you for taking the time to do this!

As we discussed yesterday Fabio, my main problem has not been addressed: You had to duplicate a lot of code that is in the XML binder classes currently.

In fact, much of this code appears copied and pasted out of the RootClassBinder (for XML) out of NHibernate's trunk.

Also, it appears that the code in your blog post is missing a few pieces of functionality that are in the RootClassBinder.

So now there are essentially two definitive sources of mapping classes in NHibernate, each with their own quirks and nuances. If new features and capabilities are added to NHibernate mappings in the future, the maintainer would likely have to add this capability in both places. This could potentially be a maintenance nightmare.

Aren't you nervous about the double-maintenance necessary to support multiple mapping sources? If any new sources spring up in the future, now it's tripple-or-worse maintenance.

This is what I was trying to explain yesterday. While it is POSSIBLE to copy and paste the logic for building up mappings from one MappingSource to another, you're essentially duplicating the logic and the mechanics of mapping and violating the DRY principle, creating the potential for major maintenance headaches.

Having two DSL's build up their own semantic models to drive the inner mapping/runtime model is going to cause problems later.

I suggest that you have ONE semantic model against which you have multiple DSLs (XML, Fluent NHibernate, etc) and the ONE semantic model translates to the mapping/runtime model.

In the future, it will be less costly and less destabilizing to add new mapping sources.

-c

________________________________

[Fabio Maulo]

On 12 nov, 20:12, "Chad Myers" <c...@chadmyers.com> wrote:
>
> Aren't you nervous about the double-maintenance necessary to support multiple mapping sources?  If any new sources spring up in the future, now it's tripple-or-worse maintenance.

No. I'm not. Because in NH-Core we will maintain XML mappings.

>
> This is what I was trying to explain yesterday. While it is POSSIBLE to copy and paste the logic for building up mappings from one MappingSource to another, you're essentially duplicating the logic and the mechanics of mapping and violating the DRY principle, creating the potential for major maintenance headaches.

I don't understand which is the logic. An assignment of a property is
a "logic" ? If so, yes there is a lot of logic and is normal when you
are reading infos from different sources. In the half of 2007 Jim
Bolla done a lot of work around binders (something like 21000 lines
generated/changed) and maintain that work is not so easy.

>
> Having two DSL's build up their own semantic models to drive the inner mapping/runtime model is going to cause problems later.
>
> I suggest that you have ONE semantic model against which you have multiple DSLs (XML, Fluent NHibernate, etc) and the ONE semantic model translates to the mapping/runtime model.  

If you want, now, you saw a way to do it. So far I can't saw a project
bypassing XML or with the intention to bypass XML. What I'm seeing are
XML generators.

>
> In the future, it will be less costly and less destabilizing to add new mapping sources.

Sure. Let me see something doing it. After that we can talk about what
is good to port and maintain in NH codebase.

Bye.
Fabio Maulo.

[Fabio Maulo]

Sorry for the mistake.
It is possible since NH1.2.0.

On 12 nov, 19:46, Fabio Maulo <fabioma...@gmail.com> wrote:
> As promisedhttp://fabiomaulo.blogspot.com/2008/11/mapping-source-how-map-class-w...

[Chad Myers]

Fabio Maulo said...

> No. I'm not. Because in NH-Core we will maintain XML mappings.

This is the fundamental problem. As long as there is ONE TRUE SOURCE,
all the other sources will be secondary and there will be version
mismatches and maintenance will be cumbersome at best.

>I don't understand which is the logic. An assignment of a property is
> a "logic" ?

You're not just assigning properties. You have conditionals, defaults,
how settings are cascaded down from parent nodes, etc.

This is all logic, where 'logic' is "Stuff that I wouldn't automatically
get just by deriving from the Configuration class"

Worse yet, you simply copied and pasted it. This is a bad DRY violation
and harms the stability and maintainability of the project.

> If so, yes there is a lot of logic and is normal when you
> are reading infos from different sources.

You're not listening to me. The vast majority (I'd estimate 90% or more)
of the code is DUPLICATED, pure copy/paste. This is not different and
should be in a base class or a decorator of some type.

> In the half of 2007 Jim Bolla done a lot of work around
> binders (something like 21000 lines
> generated/changed) and maintain that work is not so easy.

It looks like he took the first step of decoupling it from the XML. It's
in a much better position to transition to a semantic model, but it's
still heavily XML-ish (i.e. the XSD.exe-generated Hbm* classes).

> If you want, now, you saw a way to do it. So far I can't saw a project
> bypassing XML or with the intention to bypass XML. What I'm seeing are
> XML generators.

The way you showed was to essentially copy/paste the logic in the XML
binders. This is not a good way of doing it and will cause lots of pain
and bugs later. DRY is a very important principle to follow.

> Sure. Let me see something doing it. After that we can talk about what
> is good to port and maintain in NH codebase.

I volunteered before, and I'm happy to still do it, but what I'm
proposing is taking all the logic that's currently in things like
RootClassBinder and moving it into a base class and have the XML/XSD
Classes be one form of DSL (Fluent NHibernate being another, and there
could be others -- Boo, etc) on equal footing with the rest of them.

-c

[Fabio Maulo]

The same... so far I don't saw any code with the intention you are
talking about.
Code available, so far, are XML generators.
Begin something doing it. Then we can talk about what is good for NH
codebase.

So far the XML are giving us many others features as, for example:
http://fabiomaulo.blogspot.com/2008/10/less-than-gof-is-hbm.html
As you can see there is no concrete classes nor interfaces.

Or this : http://fabiomaulo.blogspot.com/2008/10/entity-name-in-action-entity.html
where we can use "conceptual-names" to create relations for
persistence without take care about its representation in C#.

Without talk about EntityMode.Xml that give us the ability to map a
class with all its states directly in the XML file.

Until what is available is only XML generators all other matters are
only words without real code.
The NH codebase is not a good place for experiments; there are too
many people and too many projects using it (even using the trunk).

Please, begin a project bypassing XML and create an example that
allowing the use of XML as a "mapping source". After that we can
restart this discussion.
Bye
Fabio Maulo.

P.S. the code attached to the post was done in around one hour and, as
I said in the post: "begin a new framework is not the target of the
post".

[Chad Myers]

I have offered 3 or 4 times to do the code and up until tonight, several
NHib maintainers have said (or alluded) that a patch would likely not be
accepted.

It also seems that the NHib team is heavily tied to XML in mind and code
and have been very resistant to any idea of breaking NHibernate away
from its heavy dependence upon XML.

As much as I'd love to see it completed and am willing to do the work,
I'm not terribly interested in spending a ton of time re-writing the
mapping model in NHibernate only to have the patch be rejected.

As long as the official, primary mapping source of NHibernate is XML and
the maintainers are firm on that point, Fluent NHibernate will most
likely have to generate XML.

I'd like to caution everyone involved (NHibernate and Fluent NHibernate
developers alike), if Fluent NHibernate goes down the road of a direct
mapping source, it could become popular and achieve "canon" parity with
the XML definition and then we'll all have a hell of a mess on our hands
and a "dual-canon" approach -- which is never nice in a DSL/Semantic
Model mapping situation.

-c

-----Original Message-----
From: fluent-n...@googlegroups.com
[mailto:fluent-n...@googlegroups.com] On Behalf Of Fabio Maulo
Sent: Wednesday, November 12, 2008 9:24 PM
To: Fluent NHibernate

[Fabio Maulo]

On 13 nov, 02:43, "Chad Myers" <c...@chadmyers.com> wrote:
> I have offered 3 or 4 times to do the code and up until tonight, several
> NHib maintainers have said (or alluded) that a patch would likely not be
> accepted.

Please refer to us as "NHibernate developers"; Thanks.
We are not maintaining the existing code, we are developing NH and its
features.

Bye.
Fabio Maulo.

[Tuna Toksöz]

Chad I really like to see Fluent Implementation for mapping, but I am not sure if i could come up with a good thing. I am ready for a collaboration always for a better design. This of course doesn't mean that I will only work on this, though. A patch is always welcome unless it is not bad and doesn't break the internals.

[Ayende Rahien]

I think that there is a misunderstanding going on.

Assuming that I can reinterpret what Fabio has said.

1) Changes to the core of NH should be taken carefully.

2) Any such change should also include the ability to extend the default mapping (which is going to be XML, unless things _drastically_ change) without having to worry about having to maintain all the other mapping sources.

3) Any such change should not put undue burden when we want to port more things from Hibernate.

Given those constraints, which I think we can all agree are reasonable, I think we can get something that would work very well.

Off the top of my head (and I didn't follow the conversation so far). Creating one to one mapping from the XML to an object structure, and then having all the other mapping source feed into that object structure, and having the actual binding happen on that object model is the best way to go.

From the XML perspective, I think we will have fairly boring code to write to map the XML to the object model, and then we can just use that.

I wouldn't consider this undue burden.

Thoughts?

On Thu, Nov 13, 2008 at 7:43 AM, Chad Myers <ch...@chadmyers.com> wrote:

[Chad Myers]

I meant the same thing. Maintaining a project is more than just development. I thought I would be insulting you by just caling you a developer.


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

-----Original Message-----
From: Fabio Maulo <fabio...@gmail.com>
Sent: Thursday, November 13, 2008 6:40 AM
To: Fluent NHibernate <fluent-n...@googlegroups.com>
Subject: [fluent-nhib] Re: Mapping source

On 13 nov, 02:43, "Chad Myers" <c...@chadmyers.com> wrote:
> I have offered 3 or 4 times to do the code and up until tonight, several
> NHib maintainers have said (or alluded) that a patch would likely not be
> accepted.

[Fabio Maulo]

We have an object model; all class metadata (namespace
NHibernate.Mapping) are our object model to map everything.
http://code.google.com/p/unhaddins/source/browse/HunabKu/src/MappingSource/MappingSource/EntityMapper.cs
198 lines with 3 "if".
3 "if" are the unresolvable "logic" matter ?
Assign defaults (of each "mapping source") are the unresolvable
"logic" matter ?
Create a new "mapping source" is not easy because:
- ORM have many options
- NH have tons of options

In this moment I don't have time to start ORuM... the real problem to
write a new "mapping source", avoiding XML, is: have time to do it.
(well.... I know... the time is necessary but is not enough).


On 13 nov, 10:11, "Ayende Rahien" <aye...@ayende.com> wrote:
> I think that there is a misunderstanding going on.Assuming that I

> can reinterpret what Fabio has said.
>
> 1) Changes to the core of NH should be taken carefully.
> 2) Any such change should also include the ability to extend the default
> mapping (which is going to be XML, unless things _drastically_ change)
> without having to worry about having to maintain all the other mapping
> sources.
> 3) Any such change should not put undue burden when we want to port more
> things from Hibernate.
>
> Given those constraints, which I think we can all agree are reasonable, I
> think we can get something that would work very well.
>
> Off the top of my head (and I didn't follow the conversation so far).
> Creating one to one mapping from the XML to an object structure, and then
> having all the other mapping source feed into that object structure, and
> having the actual binding happen on that object model is the best way to go.
>
> From the XML perspective, I think we will have fairly boring code to write
> to map the XML to the object model, and then we can just use that.
> I wouldn't consider this undue burden.
>
> Thoughts?
>

[Ayende Rahien]

a) this is the first time I see this. What _is_ this code?

b) that is the fun part, Chad is willing to do it for us :-)

[Chad Myers]

Ayende,

Yes, this is the route I'm advocating. From the looks of it, the NHib trunk is almost there. See: RootClassBinding Bind() method which takes an XmlNode (bad) and an HbmClass (good).

HbmClass is a code-generated class produed by the .NET "XSD.exe" tool, so as far as a DSL semantic model object it's not great, but it can suffice to get us to XML freedom.

So I propose moving the various *Binding classes out of the Cfg/XmlBinding folder and removing all references of them to the XmlNode objects so that they *ONLY* work against the Hbm* classes.

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

-----Original Message-----

From: Ayende Rahien <aye...@ayende.com>
Sent: Thursday, November 13, 2008 7:16 AM
To: fluent-n...@googlegroups.com <fluent-n...@googlegroups.com>
Subject: [fluent-nhib] Re: Mapping source

I think that there is a misunderstanding going on.Assuming that I
can reinterpret what Fabio has said.

1) Changes to the core of NH should be taken carefully.
2) Any such change should also include the ability to extend the default
mapping (which is going to be XML, unless things _drastically_ change)
without having to worry about having to maintain all the other mapping
sources.
3) Any such change should not put undue burden when we want to port more
things from Hibernate.

Given those constraints, which I think we can all agree are reasonable, I
think we can get something that would work very well.

Off the top of my head (and I didn't follow the conversation so far).
Creating one to one mapping from the XML to an object structure, and then
having all the other mapping source feed into that object structure, and
having the actual binding happen on that object model is the best way to go.

From the XML perspective, I think we will have fairly boring code to write
to map the XML to the object model, and then we can just use that.
I wouldn't consider this undue burden.

Thoughts?

[Ayende Rahien]

That sounds like a good idea. 

However, how are we going to handle an XML schema change?

[Chad Myers]

Fabio,

I'm happy to do it, I jut really want to make sure its done right so that everyone feels god about it and it improves NHibernate asmuch as possible.

The good news is that MOST of the work currently being done by the XmlBinders has nothing to do with XML and can be abstracted into a base class or decorator or visitor or something like that.

In order for that to work, there'll need to be a semantic model which is populated by the various DSL sources (XML, fluent API, etc).

To start with, let's make the Hbm* classes *THE* definitive mapping source model that all sources create/populate and get passed to the binders which do the real mapping work.

This essentially preserves 100% compatibility while still allowing easy addition pf new mapping sources without having to duplicate much, if any, code.

Sound like a plan?

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

-----Original Message-----
From: Fabio Maulo <fabio...@gmail.com>
Sent: Thursday, November 13, 2008 7:49 AM
To: Fluent NHibernate <fluent-n...@googlegroups.com>
Subject: [fluent-nhib] Re: Mapping source

We have an object model; all class metadata (namespace
NHibernate.Mapping) are our object model to map everything.
http://code.google.com/p/unhaddins/source/browse/HunabKu/src/MappingSource/MappingSource/EntityMapper.cs
198 lines with 3 "if".
3 "if" are the unresolvable "logic" matter ?
Assign defaults (of each "mapping source") are the unresolvable
"logic" matter ?
Create a new "mapping source" is not easy because:
- ORM have many options
- NH have tons of options

In this moment I don't have time to start ORuM... the real problem to
write a new "mapping source", avoiding XML, is: have time to do it.
(well.... I know... the time is necessary but is not enough).


On 13 nov, 10:11, "Ayende Rahien" <aye...@ayende.com> wrote:

> I think that there is a misunderstanding going on.Assuming that I
> can reinterpret what Fabio has said.
>
> 1) Changes to the core of NH should be taken carefully.
> 2) Any such change should also include the ability to extend the default
> mapping (which is going to be XML, unless things _drastically_ change)
> without having to worry about having to maintain all the other mapping
> sources.
> 3) Any such change should not put undue burden when we want to port more
> things from Hibernate.
>
> Given those constraints, which I think we can all agree are reasonable, I
> think we can get something that would work very well.
>
> Off the top of my head (and I didn't follow the conversation so far).
> Creating one to one mapping from the XML to an object structure, and then
> having all the other mapping source feed into that object structure, and
> having the actual binding happen on that object model is the best way to go.
>
> From the XML perspective, I think we will have fairly boring code to write
> to map the XML to the object model, and then we can just use that.
> I wouldn't consider this undue burden.
>
> Thoughts?
>

[Ayende Rahien]

+1

[Chad Myers]

We change it on the Hbm* classes and regenerate the XSD from there (or hand-make the change).

The XSD will no longer be the definitive specification for NHibernate maping, the Hbm* classes will. Any additions or removals from mapping options will have to be coordinated among the various maping DSLs. The more that we can automate the XSD generation, the better to avoid too much friction during changes.

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

-----Original Message-----
From: Ayende Rahien <aye...@ayende.com>
Sent: Thursday, November 13, 2008 7:55 AM
To: fluent-n...@googlegroups.com <fluent-n...@googlegroups.com>
Subject: [fluent-nhib] Re: Mapping source

That sounds like a good idea.
However, how are we going to handle an XML schema change?

On Thu, Nov 13, 2008 at 3:46 PM, Chad Myers <ch...@chadmyers.com> wrote:

>
> Ayende,
>
> Yes, this is the route I'm advocating. From the looks of it, the NHib
> trunk is almost there. See: RootClassBinding Bind() method which takes an
> XmlNode (bad) and an HbmClass (good).
>
> HbmClass is a code-generated class produed by the .NET "XSD.exe" tool, so
> as far as a DSL semantic model object it's not great, but it can suffice to
> get us to XML freedom.
>
> So I propose moving the various *Binding classes out of the Cfg/XmlBinding
> folder and removing all references of them to the XmlNode objects so that
> they *ONLY* work against the Hbm* classes.
>
>
>
>

> ----------------------
> Sent from my phone. Please excuse typos and extra characters
>
> -----Original Message-----
> From: Ayende Rahien <aye...@ayende.com>
> Sent: Thursday, November 13, 2008 7:16 AM
> To: fluent-n...@googlegroups.com <fluent-n...@googlegroups.com
> >
> Subject: [fluent-nhib] Re: Mapping source
>

> I think that there is a misunderstanding going on.Assuming that I
> can reinterpret what Fabio has said.
>
> 1) Changes to the core of NH should be taken carefully.
> 2) Any such change should also include the ability to extend the default
> mapping (which is going to be XML, unless things _drastically_ change)
> without having to worry about having to maintain all the other mapping
> sources.
> 3) Any such change should not put undue burden when we want to port more
> things from Hibernate.
>
> Given those constraints, which I think we can all agree are reasonable, I
> think we can get something that would work very well.
>
> Off the top of my head (and I didn't follow the conversation so far).
> Creating one to one mapping from the XML to an object structure, and then
> having all the other mapping source feed into that object structure, and
> having the actual binding happen on that object model is the best way to
> go.
>
> From the XML perspective, I think we will have fairly boring code to write
> to map the XML to the object model, and then we can just use that.
> I wouldn't consider this undue burden.
>
> Thoughts?
>

[Fabio Maulo]

On 13 nov, 10:51, "Chad Myers" <c...@chadmyers.com> wrote:
>
> Sound like a plan?

Doable.

Even if what I have in my mind is ORuM: use NH as OODB.
Register your class and NH will auto-map it using ORM best-practices
(with the option to define what mean best-practices for you).

[Fabio Maulo]

On 13 nov, 10:55, "Chad Myers" <c...@chadmyers.com> wrote:
> We change it on the Hbm* classes and regenerate the XSD from there (or hand-make the change).
>
> The XSD will no longer be the definitive specification for NHibernate maping, the Hbm* classes will.  Any additions or removals from mapping options will have to be coordinated among the various maping DSLs.  The more that we can automate the XSD generation, the better to avoid too much friction during changes.

Coordinated ? well... it depend on the speed of each DSLs developer.