After switching around my GetComponentColumnPrefix code, I found what
appears to be a bug that the component mapping will replace the
prefix. I hard coded the value to Ship and in my NUnit results when
running my test for Order I get
Invalid column name 'Country'.
Invalid column name 'PostalCode'
I didn't think about approaching it from the top down for the prefix
question but that makes sense. My first question:
ForTypesThatDeriveFrom(Action> populateMap,...
where as when you use the .Component method that's on the AutoMap
object it is
Component(Func..., Action> action) which seems to
>
> Should AutoMap.Component return down to Auto map for the component
>
instead of just map so I don't need to have my redundant mappings
I'm not quite sure what you mean here Chris.
In the second one for is there anyway I can reach back up to
>
convention.GetComponentColumnPrefix = type => s
Hi Andy
yeah, project work is always of prio one! One has to eat some thing at the
end of the day isn't it.
Also my projects pressure me... but still I want to try to squeeze out some
time to try to solve this problem.
On Mon, Oct 6, 2008 at 3:39 PM, Andrew Stewart <[EMAIL PROTECTED]
> wrote:
> H
Hi Gabriel,
I know, that one of the reason's why I haven't got round to looking at it
yet ;o)
Unfortunately work committments are getting in the way of me delving into
the harder problems of AutoMap at the moment.
Sorry matey.
Andy
On Mon, Oct 6, 2008 at 1:18 PM, Gabriel Schenker <[EMAIL PROTEC
I'll dig deeper into it... but it's not easy
On Mon, Oct 6, 2008 at 11:20 AM, Andrew Stewart <
[EMAIL PROTECTED]> wrote:
> Hello
> Righteo, Had a quick look over it and it seems to me that some form of
> recursion over the AutoMapper.MergeMap class will probably be a good start.
> As you can prob
Hello
Righteo, Had a quick look over it and it seems to me that some form of
recursion over the AutoMapper.MergeMap class will probably be a good start.
As you can probably see the following inheritence applies:
AutoMap --> ClassMap --> ClassMapBase,
ComponentPart --> ClassMapBase
JoinedSubClass
Doh! Didn't want to send that yet.
In essence we need to automap in a nested fashion. The reason you spotted is
possibly the same reason that inheritance isn't yet supported, but thinking
about this a little more this morning, I wonder if this could be resolved
through some sort of recursion. So y
Hi Gabriel
This sound similar to the problem I've had trying to make inheritence work
aswell.
AutoPersistenceModel
.MapEntitiesFromAssemblyOf().Where(t => t.Namespace ==
"Something")
.ForTypesThatDeriveFrom
(map =>
{
@Andy: I'm a little bit lost... and need your help
I can see what you are doing for things like References and HasMany. But the
Component part is special in that it has an additional action of type
Action> to be handled (auto-mapped). And there my problems
start... How can I "inject" or "auto-gener
Thanks for the response. I'll have a try tonight! If I succeed I'll send you
a patch
On Fri, Oct 3, 2008 at 10:21 AM, Andrew Stewart <
[EMAIL PROTECTED]> wrote:
> Hi
> I've had a "very" quick look at what your trying to do, and here's the
> problem. I don't see a reason why this can't be achieved
Hi
I've had a "very" quick look at what your trying to do, and here's the
problem. I don't see a reason why this can't be achieved, although we don't
currently support it - to add support you'd have to do something like below:
Modify the convention class to hold your convention and create a class
I have now a working version with (code snippet...)
.ForTypesThatDeriveFrom(map=>map.Component(t=>t.Address,
c=>
{
c.Map(p => p.Line1);
c.Map(p => p.Line2);
c.Map(p => p
Hi Gabriel
To be honest mate, no idea- as I've never actually done it with the normal
fluent-nhibernate.
However if fluent-nhibernate supports it then AutoMapper supports it.
Basically AutoPersitenceModel will map out as much of your model as it can
figure out by it self then it's down to you to p
14 matches
Mail list logo
