How do you avoid selecting all tables with JoinedSubClass?

[BringerOD]

Here is my mappings.

When I select a DomainEntity it tries to retrieve all data.

All I want tis the DomainEntity.

Any suggestions?


public DomainEntityMap()
{
WithTable("DomainEntity");

Id(x => x.Id, "EntityID")
.WithUnsavedValue(0)
.GeneratedBy.Identity();

Map(x => x.CreatedDate);
Map(x => x.ModifiedDate);

References(x => x.Company);
References(x => x.CreatedBy);
References(x => x.ModifiedBy);


JoinedSubClass("EntityID", PersonMap());
JoinedSubClass("EntityID", FileMap());
JoinedSubClass("EntityID", CompanyMap());
}

private static Action<AutoJoinedSubClassPart<Person>> PersonMap
()
{
return (js =>
{
js.Component(cm => cm.Name, NameMap());
js.Component(cm => cm.HomeEmail, EmailMap
("HomeEmail"));
js.Component(cm => cm.WorkEmail, EmailMap
("WorkEmail"));
js.Component(cm => cm.HomePhone, PhoneMap
("HomePhone"));
js.Component(cm => cm.WorkPhone, PhoneMap
("WorkPhone"));

js.JoinedSubClass("EntityID", UserMap());
});
}

private static Action<AutoJoinedSubClassPart<Company>>
CompanyMap()
{
return (js =>
{
js.Map(x => x.Name);

});
}

private static Action<AutoJoinedSubClassPart<File>> FileMap()
{
return (js =>
{
js.WithTableName("FileData");
js.Map(x => x.FileName);
js.Map(x => x.FileData);
js.Map(x => x.ContentType);

});
}

private static Action<AutoJoinedSubClassPart<User>> UserMap()
{
return (js =>
{
js.WithTableName("UserData");
js.Map(x => x.UserName);
js.Map(x => x.Password);
});
}


private static Action<ComponentPart<Name>> NameMap()
{
return c =>
{
c.Map(x => x.FirstName);
c.Map(x => x.MiddleName);
c.Map(x => x.LastName);
c.Map(x => x.Salutation);
c.Map(x => x.Suffix);
c.Map(x => x.Title);
};
}

[James Gregory]

Your design seems a little strange, why are you mapping everything as joined-subclasses under DomainEntity? It's more sensible to map everything individually.

[BringerOD]

I can see from the outside that it does looks strange.

One thing this does is it reduces the amount of columns you have to
make in each table that represents an entity. If this was model
driven design, when we add something to the DomainEntity, we would not
have to go to each table that representated an entity in our system
and add that column. I understand reducing the amount of columns in
not the primary goal with databases or performant.

Also, this would make it easier to query the table and see all
entities without having to union all tables together.

So your suggestion is table per class? So the properties in all the
base classes are duplicated throughout the system.

The fluent automapping just does not work with this scenario anyway.
Meaning, fluent auto map would handle one base and an one inheritance
level, but as soon as you add 3 levels of inheritance it all breaks.
I understand the convention that modifies the base class type as well
and that base class is not an abstract class. Which is probably why
automapper does not work. Just guessing.

My question is why would table per sub class query all subclasses when
all you want is the base class data? What is the purpose of that? Is
there a way to turn that off?

Also if you have a more sensible approach. I am all for it.

[BringerOD]

Also, is there a way to have the JoinedSubClass not be included in the
query? Especially, when I am not asking for the sub class entities.

Bryan

On Mar 2, 1:05 am, James Gregory <jagregory....@gmail.com> wrote:

[BringerOD]

6.2.1. Advantages

The joined strategy has the following advantages:

Using joined subclass tables results in the most normalized database
schema, meaning the schema with the least spurious or redundant data.
As more subclasses are added to the data model over time, the only
schema modification that needs to be made is the addition of
corresponding subclass tables in the database (rather than having to
change the structure of existing tables).
Relations to a base class using this strategy can be loaded through
standard joins and can use standard foreign keys, as opposed to the
machinations required to load polymorphic relations to table-per-class
base types, described below.

6.2.2. Disadvantages

Aside from certain uses of the table-per-class strategy described
below, the joined strategy is often the slowest of the inheritance
models. Retrieving any subclass requires one or more database joins,
and storing subclasses requires multiple INSERT or UPDATE statements.
This is only the case when persistence operations are performed on
subclasses; if most operations are performed on the least-derived
persistent superclass, then this mapping is very fast.

------------------
http://openjpa.apache.org/builds/1.0.2/apache-openjpa-1.0.2/docs/manual/jpa_overview_mapping_inher.html

On Mar 2, 1:05 am, James Gregory <jagregory....@gmail.com> wrote: