NHibernate.Search patch (mapping strategy abstraction)

[Andrey Shchekin (ashmind)]

Hello everyone,

I have created a patch that implements the abstraction of mapping
strategy for NHibernate.Search.
Now it is not limited to attributes.

What is the review process and when it can get integrated if
everything is ok?
Seeing some previous post in this group I started by creating a JIRA
issue:
http://nhjira.koah.net/browse/NHSR-24

But I am still interested in what is the integration estimate, because
the changes are somewhat significant and later integration can lead to
a merging problems.

Andrey Shchekin

[Ayende Rahien]

Andrey,
I tried to apply the patch, but it seems to be against an old version of NH Search, and there are a LOT of conlicts.
Can you regenerate the patch against the trunk?

[Andrey Shchekin (ashmind)]

Ayende,

That's strange, my version information currently is
URL: https://nhcontrib.svn.sourceforge.net/svnroot/nhcontrib/trunk/src/NHibernate.Search/src
Revision/Author: 1049 ayenderahien
Last commit revision: 1045
Is it a wrong version?

I re-generated and added to the issue (http://nhjira.koah.net/secure/
attachment/12956/ashmind-NHibernate.Search-ISearchMapping.patch)
Sorry for the same name.

But according to file comparer it is not really different from the
original patch (except some small stuff I added since).

[Ayende Rahien]

Applied, thanks.
We would be very happy to see another mapping strategy implemented :-)

[Tuna Toksoz]

like fluent? :)

Tuna Toksöz
Eternal sunshine of the open source mind.

http://devlicio.us/blogs/tuna_toksoz
http://tunatoksoz.com
http://twitter.com/tehlike

[Ayende Rahien]

Actually, I am thinking more about XML one.
I don't really get the fluent craze.

[Ayende Rahien]

As an aside, I can't access the JIRA, it is too slow.
I THINK that this is me, but I am not sure.
Can you close NHSR-24?

[Tuna Toksoz]

Done!

Tuna Toksöz
Eternal sunshine of the open source mind.

http://devlicio.us/blogs/tuna_toksoz
http://tunatoksoz.com
http://twitter.com/tehlike

[Andrey Shchekin (ashmind)]

Well for my project right now I just did a very simple custom mapping.
I was considering <class name="MediaItem" table="MediaItems"
search:indexed="true", but not with the changelist I already had.

Maybe later, if no one else does that.

On Oct 18, 3:32 pm, Ayende Rahien <aye...@ayende.com> wrote:
> Applied, thanks.
> We would be very happy to see another mapping strategy implemented :-)
>
> On Sun, Oct 18, 2009 at 10:25 AM, Andrey Shchekin (ashmind) <
>
>
>
> ashm...@gmail.com> wrote:
>
> > Ayende,
>
> > That's strange, my version information currently is
> > URL:

> >https://nhcontrib.svn.sourceforge.net/svnroot/nhcontrib/trunk/src/NHi...
> > Revision/Author<https://nhcontrib.svn.sourceforge.net/svnroot/nhcontrib/trunk/src/NHi...>:

> >        1049 ayenderahien
> > Last commit revision: 1045
> > Is it a wrong version?
>
> > I re-generated and added to the issue (http://nhjira.koah.net/secure/

> > attachment/12956/ashmind-NHibernate.Search-ISearchMapping.patch<http://nhjira.koah.net/secure/%0Aattachment/12956/ashmind-NHibernate....>
> > )

[Andrey Shchekin (ashmind)]

One (now known) issue with the current patch: without attributes, it
is possible to map DocumentId to a DB-only Id.
In that case, there is an issue described here
http://stackoverflow.com/questions/1583520/nhibernate-a-correct-way-to-load-entities-by-id-list-when-id-is-not-mapped

I haven't included fix into the current patch because it covers the
use case that wasn't possible before, and currently I fixed it for Id
only.
Needs a solution for both cases (Id/not Id), simple, but haven't yet
done.

On Oct 18, 3:32 pm, Ayende Rahien <aye...@ayende.com> wrote:

> Applied, thanks.
> We would be very happy to see another mapping strategy implemented :-)
>
> On Sun, Oct 18, 2009 at 10:25 AM, Andrey Shchekin (ashmind) <
>
>
>
> ashm...@gmail.com> wrote:
>
> > Ayende,
>
> > That's strange, my version information currently is
> > URL:

> >https://nhcontrib.svn.sourceforge.net/svnroot/nhcontrib/trunk/src/NHi...
> > Revision/Author<https://nhcontrib.svn.sourceforge.net/svnroot/nhcontrib/trunk/src/NHi...>:

> >        1049 ayenderahien
> > Last commit revision: 1045
> > Is it a wrong version?
>
> > I re-generated and added to the issue (http://nhjira.koah.net/secure/

> > attachment/12956/ashmind-NHibernate.Search-ISearchMapping.patch<http://nhjira.koah.net/secure/%0Aattachment/12956/ashmind-NHibernate....>
> > )

[Ayende Rahien]

I am sorry, I am not following what the problem is

[Andrey Shchekin (ashmind)]

Since the only previous mapping was attribute-based, class always had
[DocumentId] set on some property => this property had to exist.

Now, I do not use any kind of primary keys in domain model, only in
DB. But I still want to use this key in mapping.
So I create a DocumentId, but the class does not have a property with
corresponding name => QueryLoader crashes.
(btw I just understood that I have broken a previously working use
case with documentid indexed name != property name, but this is
unrelated problem)

On Oct 18, 4:01 pm, Ayende Rahien <aye...@ayende.com> wrote:
> I am sorry, I am not following what the problem is
>
> On Sun, Oct 18, 2009 at 1:53 PM, Andrey Shchekin (ashmind) <
>
>
>
> ashm...@gmail.com> wrote:
>
> > One (now known) issue with the current patch: without attributes, it
> > is possible to map DocumentId to a DB-only Id.
> > In that case, there is an issue described here
>

> >http://stackoverflow.com/questions/1583520/nhibernate-a-correct-way-t...

[Ayende Rahien]

Andrey,
In the mapping, then, you have to specify "id" as the property name, and let NH figure the rest for itself.

[Andrey Shchekin]

Thanks, that's much easier! And does not require changes to QueryLoader.

I have made a micropatch which adds a property name to documentid mapping (with default = RootClass.DefaultIdentifierColumnName).

Also it fixes the messages in SearchMappingFactory which have overlooked copy/paste errors.

Attached to this message.

[mathieu]

I tried this, had validation errors, asked this question on
stackoverflow (here : http://stackoverflow.com/questions/1585959/extend-an-xml-schema
) and came to this conclusion :
To do that, you would have to modify the existing nhibernate-
mapping.xsd, don't you ?

So, what about an "other" mapping file, alongside the .hbm.xml
(something in the likes of .hsbm.xml) ?


On 18 oct, 13:42, "Andrey Shchekin (ashmind)" <ashm...@gmail.com>

[Ayende Rahien]

Mathieu,
We _can_ change the schema, however, to allow extensions.
In fact, I think it would be a great thing to do.

[Andrey Shchekin]

There is also some kind of "meta-attributes", but they are really ugly.

My opinion is that right approach is to fix the schema and NH loader (so it adds additional attributes to the loaded schema, as it does with MetaAttributes).

I have no idea on hard it is (schema -- trivial, deserialization -- ?), but I think it is just the right thing to do.

[Ayende Rahien]

+1, but I have zero XSD knowledge.

[mathieu]

What about NHibernate.Validator like mappings ?

On 18 oct, 23:19, Andrey Shchekin <ashm...@gmail.com> wrote:
> There is also some kind of "meta-attributes", but they are really ugly.My
> opinion is that right approach is to fix the schema and NH loader (so it
> adds additional attributes to the loaded schema, as it does with
> MetaAttributes).
>
> I have no idea on hard it is (schema -- trivial, deserialization -- ?), but
> I think it is just the right thing to do.
>

[Andrey Shchekin]

Schema change is

1. add <xs:anyAttribute namespace="##other" /> to all attribute sequences

2. add <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" /> to all element choices

I'd do it myself but it is too late for sane coding today.

[Ayende Rahien]

Ditto here :-)
Will it mess up intelisense?

[Fabio Maulo]

and Loquacious ;)

2009/10/18 mathieu <mathie...@gmail.com>

--
Fabio Maulo

[Andrey Shchekin]

It should improve intellisense -- you will be able to have intellisense for any additional schema-referencing (xsi:schemaLocation) namespaces.

[Andrey Shchekin]

I think it is the other way -- NHibernate.Validator and codegen tools could *also* benefit from an extensible schema.

[Ayende Rahien]

So overall it is all goodies?

[mathieu]

fwiw, yes

On 18 oct, 23:45, Ayende Rahien <aye...@ayende.com> wrote:
> So overall it is all goodies?
>

> On Sun, Oct 18, 2009 at 11:44 PM, Andrey Shchekin <ashm...@gmail.com> wrote:
> > I think it is the other way -- NHibernate.Validator and codegen tools could
> > *also* benefit from an extensible schema.
>

[Andrey Shchekin]

Well, multi-schemed documents is one the benefits of having XML in the first place.

Except for additional work on good deserialization there are only benefits.

It seems there are [XmlAnyAttribute] and [XmlAnyElements] supported by XSD.exe, so deserialization should not be that hard.

[Fabio Maulo]

In NH and in NH we have used a custom deserialization class generator.

2009/10/18 Andrey Shchekin <ash...@gmail.com>

--
Fabio Maulo