Hi,

will it be possible with v3.0 to map multiple entities to the same table?

E.g. one entity only contains part of the columns and the other one all?

Thanks, Patrick

It's possible in 2.6 so I'd be surprised if it wasn't in 3.0...

Matt

pat wrote:

Hi,

will it be possible with v3.0 to map multiple entities to the same table?

E.g. one entity only contains part of the columns and the other one all?

Thanks, Patrick

I think it's something different than having two entities simply map onto the same table, Matt (although you have to have seen the setup first before realizing there's a different setup possible A and B mapped onto same table, with 1:1 relationship between PK's, and B (fk side) is always updating a row, it's never 'inserted')

What you refer to Patrick is entity splitting. It's used by O/R mappers who don't have the exclude/include field feature like LLBLGen Pro does.

The designer supports it, it's not sure if we can add the feature to the runtime in time. It won't be in the runtime when the beta starts, but we hope to have all open issues implemented before RTM (likely 2 months after beta starts) so it might be we can add this. On paper the feature itself isn't that hard to implement, but we want to keep the list of features to add to the runtime small, as every feature to add will make v3 become released later.

So in short: the designer supports it and has validation for it as well, it's not certain it will be in v3.0 of the runtime. If not, it will be in v3.1 (or whatever version number within 3.x we will use for the major RTL revision).

Nice.

Thanks, Patrick

Otis wrote:

The designer supports it, it's not sure if we can add the feature to the runtime in time.

Will it be supported to generate NHibernate code for entity splitting (considering that the runtime already supports it)?

Thanks, Patrick

pat wrote:

Otis wrote:

The designer supports it, it's not sure if we can add the feature to the runtime in time.

Will it be supported to generate NHibernate code for entity splitting (considering that the runtime already supports it)?

Thanks, Patrick

yes (also for EF 1/4 which also supports it, linq 2 sql doesn't so it's not generated for that)

On LLBLGen Pro you don't really need it, as you can use excluding fields. Most of the time, entity splitting is used for big-fields like image/blobs, and you can easily exclude and refetch these with llblgen pro.

Nice.

CSLA.NET also uses it a lot as it's about making business objects for a use case. e.g. one business object made up of multiple tables or one business object represents a use case with uses only a few fields of a table etc. So having this feature will help make LLBLGen a popular code gen for CSLA.NET as many code generators for CSLA.NET still build the objects straight from database tables which is the wrong approach for CSLA.NET.

Thanks, Patrick

pat wrote:

Nice.

CSLA.NET also uses it a lot as it's about making business objects for a use case. e.g. one business object made up of multiple tables or one business object represents a use case with uses only a few fields of a table etc. So having this feature will help make LLBLGen a popular code gen for CSLA.NET as many code generators for CSLA.NET still build the objects straight from database tables which is the wrong approach for CSLA.NET.

Thanks, Patrick

The only roadblock we currently see in implementing this is perhaps inheritance as you can then get all kinds of awkwardness. It's not that hard to flag an entity type for 'update only', it's more what kind of effects does it have . Anyway, we'll try to get it into the runtime before RTM.

Hi Frans,

here a quote from Rocky's CSLA.NET forum:

Rockford wrote:

Good object models almost never match the database shape. Sure, some objects do. But many important objects won’t match the database shape. Few (if any) ORM tools actually provide the flexibility to map a table (in whole or part) to n different object types. Or to map n different tables (in whole or part) to a single object type. EF doesn’t do this – in fact it can only map a table once as I understand it. So while it is a great goal for an ORM to do this, after 15+ years of people building ORMs and failing to achieve the goal, I’m not holding my breath…

http://forums.lhotka.net/forums/permalink/36097/37532/ShowThread.aspx#37532

So if LLBLGen v3 can fill this niche it's bound to spark a lot of interest.

Thanks, Patrick

For 3.0, we didn't have the time to add single entity -> multiple tables. This is a simple sounding, yet extremely complex mapping affair and we postponed that for a future v3.x release.

entity splitting, it's not yet clear if that's available in the runtime at RTM, depends on the time we have.

I don't agree with Lhotka that you should be able to map whatever model X onto whatever model Y and vice versa, because it's about meaning: both sides of a mapping are projections from the same source: the abstract entity. You can opt to choose different representations on both sides, but these representations have to be projections still.

It's doable to change a lot on either end and still be able to map one onto another, but it has a price, and it's often too high to be affordable: a lot of joins between tables to get 1 entity... is that useful? (no). Make a mess of a database just to be able to split up entities? (IMHO, no).

What's often more important are value types, e.g. an Address type with City, Housenr, Street and Country fields, and you can then set a Customer entity's VisitingAddress field to an instance of address. That gives a more fine-grained object model.

That legacy databases often suck (and new ones as well) is a given, but so do object models. Deep inheritance hierarchies or other models which are been designed without thinking about the storage they've to be persisted in... you can't always have what you want: a database isn't an object store, one has to live with that fact, and if you consider an application's execution time is often spend for a large amount inside an RDBMS, it's key to consider the DB a part of the application and not some storage facility you can add later.

Otis, Would you please give me an update on this for version 4 (mapping 1 entity to multiple tables). What is the workaround please if this is not available.

Many thanks, jp

We did add entity splitting to v3.0 (and thus it's available in all later versions)

Support for multiple entity classes with a relationship mapped onto the same target. This is called 'entity splitting' where a new entity is mapped onto the same target and has optional (nullable) fields and a 1:1 relationship between its PK and the PK of an other entity mapped onto the same target. Useful when large fields have to be in a separate entity as they're optional.

But we didn't add 1 entity mapped to multiple tables. If you need that, please either create a view which joins the rows together (which should have a 1:1 relationship) and map the entity onto the view (and add update/insert triggers), or look into whether this is an inheritance scenario, (Target Per Entity). A subtype in a TPE hierarchy is mapped onto multiple tables, namely its own table and the table(s) of the supertype(s). This might not suit your use case though.

If this is for read-only purposes, you might also look into typedlists, or create a view in the DB to map the entity on.