Breeze supports inheritance as of 1.3.2. The DocTest unit tests demonstrate TPH, TPT, and TPC inheritance, based on an Entity Framework server. I am trying to create a similar data service, with similar type inheritance, e.g BankAccount as a subtype of EntityBase, but using MongoDb in the server instead of EF. So I'm loosely following the Zza sample (except not using Angular.js).
The Zza sample does not use inheritance, and it uses a basic JSON format for its metadata. When I fetched the metadata from the DocTest
http://localhost:45678/breeze/inheritance/Metadata
it appears to be in a different format (JSDL?), so I'm stuck with trying to come up with an equivalent JSON format. Initially this looks like adding "abstract": "true" to my base type in the metadata and "baseType":"EntityBase" to derived types.
Is there any reason to think this won't work without EF? And any reason to prefer TPH (Table Per Hierarchy) over TPC (Table Per Class), for example?
The Breeze client doesn't care if the backend is EF or Mongo, and inheritance is supported for either. What is different between Mongo and EF is that with EF we are able to extract metadata about inheritance relationships from the EF model. This is not possible with Mongo because there is no real metadata about the model stored in the Mongo database. This means that with Mongo you have to create the metadata on the client via Breeze's metadata api. It is completely up to you as to whether and how to create an inheritance structure in the metadata that matches what will be returned from a Mongo query. Take a look at the http://www.breezejs.com/documentation/metadata-by-hand for more information.
Related
I just want to know how Entity Framework internally works to reveal properties and their types in runtime, particularly in case of Code-First approach, where there won't be system generated code. Can some body give some heads up? I don't think System.Reflection was being used implicitly?
Code first was first presented to developers as part of the EF Feature
CTP1 in June 2009 with the name “code only.” The basic premise behind
this variation of using the EF was that developers simply want to
define their domain classes and not bother with a physical model.
However, the EF runtime depends on that model’s XML to coerce queries
against the model into database queries and then the query results
from the database back into objects that are described by the model.
Without that metadata, the EF can’t do its job. But the metadata does
not need to be in a physical file. The EF reads those XML files once
during the application process, creates strongly typed metadata
objects based on that XML, and then does all of that interaction with
the in-memory XML.
Code first creates in-memory metadata objects, too. But instead of
creating it by reading XML files, it infers the metadata from the
domain classes (see Figure 1). It uses convention to do this and then
provides a means by which you can add additional configurations to
further refine the model.
ModelBuilder will now take this additional information into account as
it’s creating the in-memory model and working out the database schema.
By Julie Lerman
I'm using the SQLite provider for Entity Framework 5 but it doesn't support CreateDatabase and thus cannot auto create the database. (Code First)
Is there a way I can obtain the Model schema at runtime so that I can create the SQL "CREATE TABLE" command myself?
If not at runtime, some other way to obtain the schema so I know how to create the table properly?
Thanks!
A) As for obtaining the model schema at runtime part
(all are earlier posts of mine)
See this one How I can read EF DbContext metadata programmatically?
And How check by unit test that properties mark as computed in ORM model?
Also this one for a custom initializer Programmatic data transformation in EF5 Code First migration
Having said that...
The problem I see is where and at what point you actually have the data available.
Actually I'm quite sure you won't be able to do that at any time.
Because to be able to extract that info you need to have a DbContext running - so db has to be constructed etc. etc.
In the initializer maybe - but using different ways to get that info - the above is not available.
B)
The other way would be to go the way of implementing a provider, generator etc. (e.g. this post).
That way you should get all that info just at the right time from the EF/CF itself.
However I haven't played with that much.
For more info you can check the EF source code
This is more of a 'gathered info' so far - in case it helps you get anywhere with it. Not really a solution. I'll add some more tomorrow.
EDIT:
To get the real database metadata, look into the other DataSpace, this should get you to the right place...
(note: things tend to get less exact from here - as obviously there isn't the right official support)
var ssSpaceSet = objectContext.MetadataWorkspace.GetItems<EntityContainer>(DataSpace.SSpace).First()
.BaseEntitySets
.First(meta => meta.ElementType.Name == "YourTableName");
If you look up in debugger, Table property should have the real table name.
However, reflection might be required.
How I can read EF DbContext metadata programmatically?
How check by unit test that properties mark as computed in ORM model?
Programmatic data transformation in EF5 Code First migration
Entity Framework MigrationSqlGenerator for SQLite
http://entityframework.codeplex.com/
Entity Framework - Get Table name from the Entity
ef code first: get entity table name without dataannotations
Get Database Table Name from Entity Framework MetaData
http://www.codeproject.com/Articles/350135/Entity-Framework-Get-mapped-table-name-from-an-ent
trying to implement table per concrete type using model first, but when saving the derived type, EF saves to both the base and derived tables. how do you configure EF to save the type to the correct corresponding table?
There is a good discussion of choosing an approach here that recommends against TPC for Entity Framework: http://blogs.msdn.com/b/alexj/archive/2009/04/15/tip-12-choosing-an-inheritance-strategy.aspx
For this reason: While the EF runtime supports TPC, the designer doesn't, and using TPC in the EF forces you to avoid associations in your base type. Because of these issues we generally discourage the use of TPC with the Entity Framework.
My best guess is that if you are writing to a base and derived tables as your problem you have tried to implement this where you have a concrete class which is extended by an additional concrete class? As per the discussion above, the simple answer is TPC will not work like this for EF (the referenced article is 2009, but I don't think this has changed).
I am currently writing a WCF data service that is meant to extract data from any database in a predefined standard structure.
I was thinking of using POCO entities. I can design my entities on EF designer and generate the POCO classes from it but the bit I struggling to understand is how to write data access layer and inject it into the DBContext.
So for each different database, I'll have a data access layer that will retrieve data from a database or even an xml file and map the data to my POCO entities.
I am not sure if this is achievable at all.
The POCO classes will be my standard structure to expose to the world.
I can't see anywhere to write custom sql queries to extract data from a DB and then set the data in the POCO classes. The POCO classes do not match any of the database tables so I explicitly need to map database fields to the POCO classes but I am not sure how to do this in Entity Framework using POCO.
I believe POCO is the write option but struggling on the data access layer and mappings from database to POCO classes.
All the samples I have seen talk about connecting the EF to an existing database directly. Meaning the EF structure has to match the structure of the database. What I want is a single EF/POCO structure that can retrieve data from multiple databases. These databases do not have the same structure but I need to manually retrieve data from these databases and transform it into the POCO classes structures. I do not necessarily want to get data from multiple databases at once but from a single DB but want to use the same model for any database - So I guess I have to write a custom DAL for each database which gets the data from a DB and transform the data into the POCO model structure.
I would really appreciate if anyone could help me.
By the way I am new to EF so please be patient.
Have you followed this tutorial which shows you how to create model classes from a DB and query against them?
Also here is a great tutorial on using EF code-first, in which you build your POCO classes first, and it generates the DB for you. Great read :).
Trying to understand Entity Framework. My approach is database first. However I would like to define other entites in the model that is closer to my business objects. I guess I could write queries in the db and include them in the model. But I would also like to define entirely new entities in the model though they would be based on underlying tables in the db. How do I do that - does anyone know a tutorial?
Regards
Bjørn
db Oldtimer, EF Newbie
Database first means that you have existing database and you can either create model by updating from database or manually. You can use wizard to create initial model and modify it manually to define new entities but you must not use update from database any more or some of your changes will be deleted. Also your custom modifications must follow EF mapping rules (for example it is not directly possible to map multiple entities to the same table except some more advanced mapping scenarios like splitting and inheritance) and some of them (custom queries) must be done directly in EDMX source (XML) because designer doesn't support them - this requires more complex knowledge of EF mapping and it will be definitely hard for newbie.
You can check specification of that XML. For entities mapped to custom queries you will have to use DefiningQuery element in SSDL part of EDMX.