AutoPersisenceModel not working

[Marco]

It seems it's still necessary to include the ClassMap<T>
instances..Anyone else experiencing this?

Thanks
Marco

[Marco]

I tried to modify the NhibernateSession.AddMappingAssembliesTo into
the code below, but still not working..

private static void AddMappingAssembliesTo(Configuration cfg, string[]
mappingAssemblies) {
Check.Require(mappingAssemblies != null && mappingAssemblies.Length
>= 1,
"mappingAssemblies must be provided as a string array of assembly
names which contain mapping artifacts. " +
"The artifacts themselves may be HBMs or ClassMaps. You may
optionally include '.dll' on the assembly name.");
var persistenceModel = new AutoPersistenceModel();
persistenceModel.WithConvention(
convention => {
convention.FindIdentity = p => p.GetCustomAttributes(typeof
(DomainSignatureAttribute), true).Length == 0;
});


foreach (string mappingAssembly in mappingAssemblies) {
string loadReadyAssemblyName = (mappingAssembly.IndexOf(".dll") ==
-1)
? mappingAssembly.Trim() + ".dll"
: mappingAssembly.Trim();

Assembly assemblyToInclude = Assembly.LoadFrom
(loadReadyAssemblyName);
// Looks for any HBMs
cfg.AddAssembly(assemblyToInclude);
// Looks for any Fluent NHibernate ClassMaps
//cfg.AddMappingsFromAssembly(assemblyToInclude);
persistenceModel.AddEntityAssembly(assemblyToInclude)
.Where(t => typeof(IDomainObject).IsAssignableFrom(t));
}
persistenceModel.Configure(cfg);

[Billy]

Marco,

I've been knee deep in T4 templates for scaffol generation and have
not gotten an opportunity to review this item yet. If you are able to
take any more time to review this item or have made further progress
on leveraging AutoPersistenceModel, your findings and/or guidance
would be appreciated.

Thanks!
Billy

[demol]

Any updates on that?

[]´s

> >                                 // Looks for anyFluentNHibernate ClassMaps

[Alec Whittington]

There is some good information on this over on the Fluent NHibernate google group. I believe Ayende (Oren) has taken an interest in it, so more is being done with it. Might want to head over to their group google site and go through the discussions there.

Alec Whittington

[Kyle Baley]

For those who haven't seen them, James Gregory is doing a great series of posts on Fluent NHibernate. The first is here:

 

http://blog.jagregory.com/2009/01/10/fluent-nhibernate-auto-mapping-introduction/

 

I did some playing and I think S#arp needs to be updated to use a later version of Fluent NHibernate to accommodate what he's showing. Tried to incorporate it this morning but I always forget how to strongly name assemblies and got distracted looking it up...

[demol]

Good posts...
I think S#arp should incorporate automap...

On 12 jan, 00:58, "Kyle Baley" <k...@baley.org> wrote:
> For those who haven't seen them, James Gregory is doing a great series of
> posts on Fluent NHibernate. The first is here:
>

> http://blog.jagregory.com/2009/01/10/fluent-nhibernate-auto-mapping-i...

>
> I did some playing and I think S#arp needs to be updated to use a later
> version of Fluent NHibernate to accommodate what he's showing. Tried to
> incorporate it this morning but I always forget how to strongly name
> assemblies and got distracted looking it up...
>
> On Tue, Dec 16, 2008 at 11:27 AM, Alec Whittington <
>

> alec.whitting...@gmail.com> wrote:
> > There is some good information on this over on the Fluent NHibernate google
> > group. I believe Ayende (Oren) has taken an interest in it, so more is being
> > done with it. Might want to head over to their group google site and go
> > through the discussions there.
> > Alec Whittington
>

[Kyle Baley]

I'm back at this trying to incorporate the latest version of Fluent NHibernate. How are we handling strong naming of the third-party assemblies like Windsor and Fluent NHibernate? Do I need to disassemble FluentNHibernate.dll, then re-assemble it with the S#arp key file?

[Simone Busoli]

How do others do it?

[Kyle Baley]

Not sure about the other third-party libs but I just discovered Fluent NHibernate has a key already. I re-compiled it using that and it seems to have worked.

[Billy]

As you just found, it doesn't have to be a S#arp Arch key...it just
has to be strongly signed with anything. Most of the assemblies that
S#arp Arch uses are strongly signed. The only one that I haven't been
able to get signed is MvcContrib since it's also dependent on some
unsigned assemblies. Consequently, only SharpArch.Web remains
unsigned out of the SharpArch libraries.

Billy

On Jan 12, 2:23 pm, "Kyle Baley" <k...@baley.org> wrote:
> Not sure about the other third-party libs but I just discovered Fluent
> NHibernate has a key already. I re-compiled it using that and it seems to
> have worked.
>

> On Mon, Jan 12, 2009 at 4:09 PM, Simone Busoli <simone.bus...@gmail.com>wrote:
>
> > How do others do it?
>

> > On Mon, Jan 12, 2009 at 9:47 PM, Kyle Baley <k...@baley.org> wrote:
>
> >> I'm back at this trying to incorporate the latest version of Fluent
> >> NHibernate. How are we handling strong naming of the third-party assemblies
> >> like Windsor and Fluent NHibernate? Do I need to disassemble
> >> FluentNHibernate.dll, then re-assemble it with the S#arp key file?
>

[Simone Busoli]

I don't think there should be issues with referencing their strong named assemblies.

[Kyle Baley]

Has anyone taken a stab at getting the auto persistence working? I've been working on it for the better part of an afternoon with the Northwind sample with *very* limited success. Will go into details in a bit but wanted to see what others' experience has been.

[Kyle Baley]

I got the final bit of Fluent NHibernate going for just the category page in the Northwind sample. But I ran into enough issues that I won't be creating a patch for it. Here is a summary:

 

- Had to rename the database table to Category. I don't think Fluent NHibernate has a "pluralizer" like the scaffolding does. Which means the typical EntityName + "s" convention won't work.

- Fluent NHibernate does *not* like the inheritance structure of S#arp. I had to change the Category class so that it didn't inherit from anything. Otherwise, I ended up with mappings only for PersistentObject and PersistentObjectWithTypedId. And even then, I had to modify some Fluent NHibernate code to get that far.

- The auto mappings need to be included in the configuration before the session factory is created. Which means at least one more overload (probably more) for the Init method of NHibernateSession

- Fluent NHibernate doesn't like static classes (e.g. OrdersExtensions) in the domain assembly.

There could be work-arounds for some of these (the last item for example has an easy one). I know there is a way to override conventions for individual classes and/or to use both ClassMaps and auto mapping in conjunction. Will be something to look into I suppose but not by me for at least a few days after today's bout of frustration. Am happy to expand via Skype or something more verbose if someone wants more detail.

 

In the end, I think S#arp requires only the overload for the Init method to support auto mapping. Everything else, like the conventions, should be provided by the application.

 

Kyle

[Billy]

Kyle,

Thank you very much for taking the time to analyze the compatibility.
It seems to me that the troubles you ran into almost make it
prohibitive to try to use it for any serious development. Or do you
feel that it's mostly just incompatible with the conventions that have
been chosen for #arch?

In summary, what's your assessment of the usefulness of providing
support for it? (It seems negative, but please correct me if I've
inferred wrongly.)

Thank you again,
Billy

> On Mon, Jan 12, 2009 at 6:29 PM, Kyle Baley <k...@baley.org> wrote:
> > Has anyone taken a stab at getting the auto persistence working? I've been
> > working on it for the better part of an afternoon with the Northwind sample
> > with *very* limited success. Will go into details in a bit but wanted to see
> > what others' experience has been.
>

> > On Mon, Jan 12, 2009 at 4:27 PM, Simone Busoli <simone.bus...@gmail.com>wrote:
>
> >> I don't think there should be issues with referencing their strong named
> >> assemblies.
>

> >> On Mon, Jan 12, 2009 at 10:23 PM, Kyle Baley <k...@baley.org> wrote:
>
> >>> Not sure about the other third-party libs but I just discovered Fluent
> >>> NHibernate has a key already. I re-compiled it using that and it seems to
> >>> have worked.
>

> >>> On Mon, Jan 12, 2009 at 4:09 PM, Simone Busoli <simone.bus...@gmail.com>wrote:
>
> >>>> How do others do it?
>

> >>>> On Mon, Jan 12, 2009 at 9:47 PM, Kyle Baley <k...@baley.org> wrote:
>
> >>>>> I'm back at this trying to incorporate the latest version of Fluent
> >>>>> NHibernate. How are we handling strong naming of the third-party assemblies
> >>>>> like Windsor and Fluent NHibernate? Do I need to disassemble
> >>>>> FluentNHibernate.dll, then re-assemble it with the S#arp key file?
>

[Kyle Baley]

I'd say it warrants some investigation by someone more familiar with Fluent NHibernate. The main stumbling block I see is that it wants to map the base classes, rather than the actual domain objects. I imagine there is a convention that can be created to work around this because I find it hard to believe this is the first project using Fluent NHibernate that uses a base class in its domain.

 

Assuming this could be fixed, I think the change to #arch itself would be minimal. Just need to incorporate an AutoPersistentModel parameter into the Init overloads on NHibernateSession. Most of the work would be in converting the sample app to use it. And I can only imagine how amenable Northwind is to conventions.

[Luis Abreu]

Yes, they have. Unfortunately the project isn’t configured by default to use it (at least, that was the scenario when I first downloaded it). Btw, can anyone confirm it they’ve added the attribute for allowing partial trusted callers?

 

Thanks.

 

<br

[Luis Abreu]

Yes, that is correct (I’ve done that in the past).

 

From: sharp-arc...@googlegroups.com [mailto:sharp-arc...@googlegroups.com] On Behalf Of Simone Busoli
Sent: segunda-feira, 12 de Janeiro de 2009 21:28
To: sharp-arc...@googlegroups.com
Subject: Re: AutoPersisenceModel not working

 

I don't think there should be issues with referencing their strong named assemblies.

[Luis Abreu]

My main problem with autopersistence is inheritance and custom versioning. Ex.: I’ve got base class  for all entities and my versions are timestamps (sql server). I believe you can get the code for the inflector has been added to their project (or will be in a near future) so you should be able to pluralize their names. The inheritance problem can be solved by setting the IsBaseclass on the conventions.

 

From: sharp-arc...@googlegroups.com [mailto:sharp-arc...@googlegroups.com] On Behalf Of Kyle Baley
Sent: terça-feira, 13 de Janeiro de 2009 02:53
To: sharp-arc...@googlegroups.com
Subject: Re: AutoPersisenceModel not working

 

I got the final bit of Fluent NHibernate going for just the category page in the Northwind sample. But I ran into enough issues that I won't be creating a patch for it. Here is a summary:

[Luis Abreu]

There is the IsBaseClass entry on the convetion object which you can use to skip the base class and to get the correct behavior on the mappings. It will not work if you have to customize any of the fields (ex.: suppose you have a version field of type timestamp (sql server). In this case, you can have the automappings but then you need to add specific entries for all the entities so that the version is correctly set up. In these cases, the mappings won’t work. But if you’re  using the traditional int version field, then the IsBaseClass entry should solve the current problems).

 

From: sharp-arc...@googlegroups.com [mailto:sharp-arc...@googlegroups.com] On Behalf Of Kyle Baley
Sent: terça-feira, 13 de Janeiro de 2009 03:40
To: sharp-arc...@googlegroups.com
Subject: Re: AutoPersisenceModel not working

 

I'd say it warrants some investigation by someone more familiar with Fluent NHibernate. The main stumbling block I see is that it wants to map the base classes, rather than the actual domain objects. I imagine there is a convention that can be created to work around this because I find it hard to believe this is the first project using Fluent NHibernate that uses a base class in its domain.

[Kyle Baley]

Is this the IsBaseType convention? That's the one I was having trouble with. The default convention returns false for any #arch domain objects which led to class mappings for the PersistentObject classes. I changed that so that it always returns true but then the classes don't ever get added to the mapping. This is because there is a check in the AutoPersistenceModel.Configure method that skips over classes where IsBaseType is true.

 

It could be some combination of other changes that kept it from working for me as I was in heavy hack mode after the first hour. It looked to me like it should work out of the box because it appears to examine a base class and map any classes deriving from it, which is actually more efficient. But when the mappings are actually added to the configuration, only the PersistentObject classes are there.

[James Gregory]

What does your IsBaseType convention look like? What's the inheritance
hierarchy for your entities?

convention.IsBaseType = (type => type == typeof(MyBaseClass));

That should work fine.

Most everything else you said should be able to be handled through the
conventions. The static class was a bug on our part, which Andrew has
since fixed.

James

On Jan 13, 1:14 pm, "Kyle Baley" <k...@baley.org> wrote:
> Is this the IsBaseType convention? That's the one I was having trouble with.
> The default convention returns false for any #arch domain objects which led
> to class mappings for the PersistentObject classes. I changed that so that
> it always returns true but then the classes don't ever get added to the
> mapping. This is because there is a check in the
> AutoPersistenceModel.Configure method that skips over classes where
> IsBaseType is true.
>
> It could be some combination of other changes that kept it from working for
> me as I was in heavy hack mode after the first hour. It looked to me like it
> should work out of the box because it appears to examine a base class and
> map any classes deriving from it, which is actually more efficient. But when
> the mappings are actually added to the configuration, only the
> PersistentObject classes are there.
>
> On Tue, Jan 13, 2009 at 5:23 AM, Luis Abreu <lab...@gmail.com> wrote:
> >  There is the IsBaseClass entry on the convetion object which you can use
> > to skip the base class and to get the correct behavior on the mappings. It
> > will not work if you have to customize any of the fields (ex.: suppose you
> > have a version field of type timestamp (sql server). In this case, you can
> > have the automappings but then you need to add specific entries for all the
> > entities so that the version is correctly set up. In these cases, the
> > mappings won't work. But if you're  using the traditional int version field,
> > then the IsBaseClass entry should solve the current problems).
>

> > *From:* sharp-arc...@googlegroups.com [mailto:
> > sharp-arc...@googlegroups.com] *On Behalf Of *Kyle Baley
> > *Sent:* terça-feira, 13 de Janeiro de 2009 03:40
> > *To:* sharp-arc...@googlegroups.com
> > *Subject:* Re: AutoPersisenceModel not working

>
> > I'd say it warrants some investigation by someone more familiar with Fluent
> > NHibernate. The main stumbling block I see is that it wants to map the base
> > classes, rather than the actual domain objects. I imagine there is a
> > convention that can be created to work around this because I find it hard to
> > believe this is the first project using Fluent NHibernate that uses a base
> > class in its domain.
>
> > Assuming this could be fixed, I think the change to #arch itself would be
> > minimal. Just need to incorporate an AutoPersistentModel parameter into the
> > Init overloads on NHibernateSession. Most of the work would be in converting
> > the sample app to use it. And I can only imagine how amenable Northwind is
> > to conventions.
>

> > On Mon, Jan 12, 2009 at 10:31 PM, Billy <googlegro...@emccafferty.com>

> ...
>
> read more »

[Luis Abreu]

If I got it right, you should be able to do what you want by passing something like this on the convetions:

convention.IsBaseType = (type => type == typeof(PersistentObject));

 

now, I haven’t looked at the current version, but I do recall that there are probably several base classes so you’d probably have to perform several checks for all the base classes which shouldn’t be rendered.

 

PS: I think that fluent NH is still a little bit away for getting automatic mappings working for all cases, but…

 

 

<br

[James Gregory]

If I got it right, you should be able to do what you want by passing something like this on the convetions:

convention.IsBaseType = (type => type == typeof(PersistentObject));

That looks correct.

PS: I think that fluent NH is still a little bit away for getting automatic mappings working for all cases, but…

Luis, please direct any outstanding problems you may have with FNH to the FNH mailing list, lets not pollute this discussion with them.

[Kyle Baley]

Actually, it would have to account for cases where a class derives directly from PersistentObjectWithTypedId<T> as well (like the Customers class in the Northwind sample).

 

The next problem I'm having (and apologies, James, for repeating myself here and on Twitter): The convention for the name of the ID is type.Name + "ID". Except that when the mapping is generated, it's using the type of the base class, PersistentObjectWithTypedId<T>, rather than, say, Category.

[James Gregory]

Ah, (I actually misunderstood you on twitter) that looks like a bug to me. I'll try to investigate this tonight.

[Kyle Baley]

I believe Fluent NHibernate can provide a lot of value for greenfield projects but may be harder for brownfield ones where the database doesn't follow an easy convention. Like Northwind.

[Billy]

Personally, I would like to put very little concern towards supporting
a horribly designed database like Northwind with
AutoPersistenceModel. (The nice thing is that it's made #arch a lot
more extensible in having to deal with it!) If users want to support
a DB like Northwind, or have more surgical control of mappings, they
can use NHibernate ClassMaps. Otherwise, I have no qualms with
dictating a few conventions (or at least anti-conventions to be
avoided) if a developer wants to use AutoPersistenceModel with S#arp
Architecture projects. The question is, what conventions and/or
avoidance of anti-conventions must be in place for this?

We can set up another sample web project which points to a very simple
database following the decided conventions.

Billy

On Jan 13, 9:21 am, "Kyle Baley" <k...@baley.org> wrote:
> I believe Fluent NHibernate can provide a lot of value for greenfield
> projects but may be harder for brownfield ones where the database doesn't
> follow an easy convention. Like Northwind.
>
> On Tue, Jan 13, 2009 at 10:02 AM, Luis Abreu <lab...@gmail.com> wrote:
> >  If I got it right, you should be able to do what you want by passing
> > something like this on the convetions:
>
> > convention.IsBaseType = (type => type == typeof(PersistentObject));
>
> > now, I haven't looked at the current version, but I do recall that there
> > are probably several base classes so you'd probably have to perform several
> > checks for all the base classes which shouldn't be rendered.
>
> > PS: I think that fluent NH is still a little bit away for getting automatic
> > mappings working for all cases, but…
>

> > *From:* sharp-arc...@googlegroups.com [mailto:
> > sharp-arc...@googlegroups.com] *On Behalf Of *Kyle Baley

> > *Sent:* terça-feira, 13 de Janeiro de 2009 13:14
>
> > *To:* sharp-arc...@googlegroups.com
> > *Subject:* Re: AutoPersisenceModel not working

>
> > Is this the IsBaseType convention? That's the one I was having trouble
> > with. The default convention returns false for any #arch domain objects
> > which led to class mappings for the PersistentObject classes. I changed that
> > so that it always returns true but then the classes don't ever get added to
> > the mapping. This is because there is a check in the
> > AutoPersistenceModel.Configure method that skips over classes where
> > IsBaseType is true.
>
> > It could be some combination of other changes that kept it from working for
> > me as I was in heavy hack mode after the first hour. It looked to me like it
> > should work out of the box because it appears to examine a base class and
> > map any classes deriving from it, which is actually more efficient. But when
> > the mappings are actually added to the configuration, only the
> > PersistentObject classes are there.
>
> > On Tue, Jan 13, 2009 at 5:23 AM, Luis Abreu <lab...@gmail.com> wrote:
>
> > There is the IsBaseClass entry on the convetion object which you can use to
> > skip the base class and to get the correct behavior on the mappings. It will
> > not work if you have to customize any of the fields (ex.: suppose you have a
> > version field of type timestamp (sql server). In this case, you can have the
> > automappings but then you need to add specific entries for all the entities
> > so that the version is correctly set up. In these cases, the mappings won't
> > work. But if you're  using the traditional int version field, then the
> > IsBaseClass entry should solve the current problems).
>

> > *From:* sharp-arc...@googlegroups.com [mailto:
> > sharp-arc...@googlegroups.com] *On Behalf Of *Kyle Baley
> > *Sent:* terça-feira, 13 de Janeiro de 2009 03:40
>
> > *To:* sharp-arc...@googlegroups.com

> > *Subject:* Re: AutoPersisenceModel not working

>
> > I'd say it warrants some investigation by someone more familiar with Fluent
> > NHibernate. The main stumbling block I see is that it wants to map the base
> > classes, rather than the actual domain objects. I imagine there is a
> > convention that can be created to work around this because I find it hard to
> > believe this is the first project using Fluent NHibernate that uses a base
> > class in its domain.
>
> > Assuming this could be fixed, I think the change to #arch itself would be
> > minimal. Just need to incorporate an AutoPersistentModel parameter into the
> > Init overloads on NHibernateSession. Most of the work would be in converting
> > the sample app to use it. And I can only imagine how amenable Northwind is
> > to conventions.
>

> > On Mon, Jan 12, 2009 at 10:31 PM, Billy <googlegro...@emccafferty.com>

> ...
>
> read more »

[Luis Abreu]

Yeah, there are still some things which need some work, but after following their list for a few days, I’m really under the impression that they will be updating it into what we need for cases like these.

 

<br

[James Gregory]

Kyle, I've addressed the problem you were having with the GetPrimaryKeyNameFromType convention; it now receives the correct type.

[Jay Oliver]

I don't know if you got this resolved yet or not since the
conversation was happening in multiple places.

I believe the problem you're still having is also consistent with the
IsBaseType convention not being setup to match
PersistentObjectWithTypedId<T>.

I don't have a convenient way to test this right now, but I think
something like this will solve your problems (would be easier if C#
had generic covariance...)

convention.IsBaseType = (type => type == typeof(PersistentObject) ||

(type.IsGenericType && type.GetGenericTypeDefinition == typeof
(PersistentObjectWithTypedId<T>));

On Jan 13, 11:07 am, "Kyle Baley" <k...@baley.org> wrote:
> Actually, it would have to account for cases where a class derives directly
> from PersistentObjectWithTypedId<T> as well (like the Customers class in the
> Northwind sample).
>
> The next problem I'm having (and apologies, James, for repeating myself here
> and on Twitter): The convention for the name of the ID is type.Name + "ID".
> Except that when the mapping is generated, it's using the type of the base
> class, PersistentObjectWithTypedId<T>, rather than, say, Category.
>

> On Tue, Jan 13, 2009 at 10:06 AM, James Gregory <jagregory....@gmail.com>wrote:
>
> >  If I got it right, you should be able to do what you want by passing
> >> something like this on the convetions:
>
> >> convention.IsBaseType = (type => type == typeof(PersistentObject));
>
> > That looks correct.
>
> > PS: I think that fluent NH is still a little bit away for getting automatic
> >> mappings working for all cases, but…
>
> > Luis, please direct any outstanding problems you may have with FNH to the
> > FNH mailing list, lets not pollute this discussion with them.
>
> > On Tue, Jan 13, 2009 at 3:02 PM, Luis Abreu <lab...@gmail.com> wrote:
>
> >>  If I got it right, you should be able to do what you want by passing
> >> something like this on the convetions:
>
> >> convention.IsBaseType = (type => type == typeof(PersistentObject));
>
> >> now, I haven't looked at the current version, but I do recall that there
> >> are probably several base classes so you'd probably have to perform several
> >> checks for all the base classes which shouldn't be rendered.
>
> >> PS: I think that fluent NH is still a little bit away for getting
> >> automatic mappings working for all cases, but…
>

> >> *From:* sharp-arc...@googlegroups.com [mailto:
> >> sharp-arc...@googlegroups.com] *On Behalf Of *Kyle Baley
> >> *Sent:* terça-feira, 13 de Janeiro de 2009 13:14
> >> *To:* sharp-arc...@googlegroups.com

> >> *Subject:* Re: AutoPersisenceModel not working

>
> >> Is this the IsBaseType convention? That's the one I was having trouble
> >> with. The default convention returns false for any #arch domain objects
> >> which led to class mappings for the PersistentObject classes. I changed that
> >> so that it always returns true but then the classes don't ever get added to
> >> the mapping. This is because there is a check in the
> >> AutoPersistenceModel.Configure method that skips over classes where
> >> IsBaseType is true.
>
> >> It could be some combination of other changes that kept it from working
> >> for me as I was in heavy hack mode after the first hour. It looked to me
> >> like it should work out of the box because it appears to examine a base
> >> class and map any classes deriving from it, which is actually more
> >> efficient. But when the mappings are actually added to the configuration,
> >> only the PersistentObject classes are there.
>
> >> On Tue, Jan 13, 2009 at 5:23 AM, Luis Abreu <lab...@gmail.com> wrote:
>
> >> There is the IsBaseClass entry on the convetion object which you can use
> >> to skip the base class and to get the correct behavior on the mappings. It
> >> will not work if you have to customize any of the fields (ex.: suppose you
> >> have a version field of type timestamp (sql server). In this case, you can
> >> have the automappings but then you need to add specific entries for all the
> >> entities so that the version is correctly set up. In these cases, the
> >> mappings won't work. But if you're  using the traditional int version field,
> >> then the IsBaseClass entry should solve the current problems).
>

> >> *From:* sharp-arc...@googlegroups.com [mailto:
> >> sharp-arc...@googlegroups.com] *On Behalf Of *Kyle Baley

> >> *Sent:* terça-feira, 13 de Janeiro de 2009 03:40
>
> >> *To:* sharp-arc...@googlegroups.com
> >> *Subject:* Re: AutoPersisenceModel not working

>
> >> I'd say it warrants some investigation by someone more familiar with
> >> Fluent NHibernate. The main stumbling block I see is that it wants to map
> >> the base classes, rather than the actual domain objects. I imagine there is
> >> a convention that can be created to work around this because I find it hard
> >> to believe this is the first project using Fluent NHibernate that uses a
> >> base class in its domain.
>
> >> Assuming this could be fixed, I think the change to #arch itself would be
> >> minimal. Just need to incorporate an AutoPersistentModel parameter into the
> >> Init overloads on NHibernateSession. Most of the work would be in converting
> >> the sample app to use it. And I can only imagine how amenable Northwind is
> >> to conventions.
>

> >> On Mon, Jan 12, 2009 at 10:31 PM, Billy <googlegro...@emccafferty.com>

> ...
>
> read more »

[Kyle Baley]

I'm playing with it now based on James's Fluent NHibernate fix and the most recent #arch changes. I was literally typing in the updated IsBaseType when this e-mail come through. Thanks for the impeccable timing.

 

I managed to get it working with a Category object in very short order with minimal changes to the base solution and with reasonable conventions in the sample app. It required two major changes:

- Included Inflector.NET to allow for pluralizing

- Rename the Name property to CategoryName. I think this can be avoided with a convention of "Prepend type name to property" whenever the property is called Name. The Product class follows this same convention.

 

Just trying to work out a way to incorporate both ClassMaps and auto-persistence as I'm told it's possible. As it stands, the Customer class is causing grief with auto-persistence because the properties aren't virtual. Which leads me to wonder how it works with the ClassMap.

[Jay Oliver]

If you want to be able to use lazy loading, I believe the properties
need to be virtual anyway because of how proxies have to work in .NET,
so that may not be that much of an issue.

However, whether or not that turns out to be an issue, there are some
other things I've run into when trying to mix auto mapping and class
maps.

Here's what I've found so far, hopefully it helps you avoid some pain:

If you're going to do a cfg.AddMappingsFromAssembly as well as have
the autoPersistenceModel.Configure(cfg), and all of these namespaces
are in the same assembly it's going to try to map the ClassMap's twice
and throw an exception.

You should be able to construct the lambda to
AutoPersistenceModel.AddEntityAssembly to avoid mapping things that
inherit from ClassMaps. Since .NET doesn't have an easy way to check
whether or not something is a generic type, I use this something like
this function to make my life easier: (you would pass it ClassMap<T>
for the second argument).

public static bool IsDerivedFromGenericType(Type givenType,
Type genericType)
{
if (givenType.IsGenericType &&
givenType.GetGenericTypeDefinition() == genericType)
return true;

Type baseType = givenType.BaseType;

if (baseType != null)
return IsDerivedFromGenericType(baseType,
genericType);

return false;
}

One alternative to this approach would be to use AutoMap<T> instead of
ClassMap<T> and only map the things that are different from what the
convention would dictate. I haven't used this a lot, and I'm not sure
in what scenarios it falls apart under yet. In order to do this, you
need to call the
AutoPersistenceModel.MergeWithAutoMapsFromAssemblyOf<T> function
before you allow the model to configure the Configuration object.

If you don't like either of those options, the last alternative I know
of is to just use the automapper (no classmaps) but override the
handling of certain types with the ForTypesThatDeriveFrom<T> fluent
method, that lets you use a lambda to change how that specific type is
mapped.

Hope some of that helps you save some aggravation.

On Jan 14, 7:02 pm, "Kyle Baley" <k...@baley.org> wrote:
> I'm playing with it now based on James's Fluent NHibernate fix and the most
> recent #arch changes. I was literally typing in the updated IsBaseType when
> this e-mail come through. Thanks for the impeccable timing.
>
> I managed to get it working with a Category object in very short order with
> minimal changes to the base solution and with reasonable conventions in the
> sample app. It required two major changes:
> - Included Inflector.NET to allow for pluralizing
> - Rename the Name property to CategoryName. I think this can be avoided with
> a convention of "Prepend type name to property" whenever the property is
> called Name. The Product class follows this same convention.
>
> Just trying to work out a way to incorporate both ClassMaps and
> auto-persistence as I'm told it's possible. As it stands, the Customer class
> is causing grief with auto-persistence because the properties aren't
> virtual. Which leads me to wonder how it works with the ClassMap.
>

> ...
>
> read more »

[Jay Oliver]

This is probably a sign I should give up for the night and go home. I
have no idea why I typed namespaces in the line below, I meant
entities.

[Luis Abreu]

Didi you set the default lazy mode on the conventions? If you don’t, then I think it will assume lazy loading by default…

[James Gregory]

Lazy load is the default, you only need to specify if you don't want it to lazy load with the conventions.

[Kyle Baley]

Yes, and in the sample app, Customer has lazy loading turned off. I got an error when it was on but wasn't in a frame of mind to investigate. It couldn't load the Orders, I believe.

[Kyle Baley]

But this brings up a good side point. The text for the link in the sample app says "Load customers with lazy loading" (or something similar) but the ClassMap for Customer turns it off.

[Billy]

Although the customers are not lazily loaded, the customer *orders*
are being lazily loaded. I will clarify that on the demo page.

Billy

On Jan 15, 6:18 am, "Kyle Baley" <k...@baley.org> wrote:
> But this brings up a good side point. The text for the link in the sample
> app says "Load customers with lazy loading" (or something similar) but the
> ClassMap for Customer turns it off.
>

> On Thu, Jan 15, 2009 at 8:17 AM, Kyle Baley <k...@baley.org> wrote:
> > Yes, and in the sample app, Customer has lazy loading turned off. I got an
> > error when it was on but wasn't in a frame of mind to investigate. It
> > couldn't load the Orders, I believe.
>

> > On Thu, Jan 15, 2009 at 4:22 AM, James Gregory <jagregory....@gmail.com>wrote:
>
> >> Lazy load is the default, you only need to specify if you don't want it
> >> to lazy load with the conventions.
>
> >> On Thu, Jan 15, 2009 at 9:20 AM, Luis Abreu <lab...@gmail.com> wrote:
>
> >>>  Didi you set the default lazy mode on the conventions? If you don't,
> >>> then I think it will assume lazy loading by default…
>

> >>> *From:* sharp-arc...@googlegroups.com [mailto:
> >>> sharp-arc...@googlegroups.com] *On Behalf Of *Kyle Baley

> >>> *Sent:* quinta-feira, 15 de Janeiro de 2009 00:02

>
> >>> *To:* sharp-arc...@googlegroups.com
> >>> *Subject:* Re: AutoPersisenceModel not working
>

> >>> I'm playing with it now based on James's Fluent NHibernate fix and the
> >>> most recent #arch changes. I was literally typing in the updated IsBaseType
> >>> when this e-mail come through. Thanks for the impeccable timing.
>
> >>> I managed to get it working with a Category object in very short order
> >>> with minimal changes to the base solution and with reasonable conventions in
> >>> the sample app. It required two major changes:
>
> >>> - Included Inflector.NET to allow for pluralizing
>
> >>> - Rename the Name property to CategoryName. I think this can be avoided
> >>> with a convention of "Prepend type name to property" whenever the property
> >>> is called Name. The Product class follows this same convention.
>
> >>> Just trying to work out a way to incorporate both ClassMaps and
> >>> auto-persistence as I'm told it's possible. As it stands, the Customer class
> >>> is causing grief with auto-persistence because the properties aren't
> >>> virtual. Which leads me to wonder how it works with the ClassMap.
>

> ...
>
> read more »