I was used to work with Zend Db Table Relationships with MySQL. I declared $_dependentTables and $_referenceMap in the table classes as described in the manual. Then was able to work with functions findDependentRowset(), findParentRow() etc.
Now I use PostgreSQL, which is able to define the relations (REFERENCES) between tables right in the database.
The manual states:
Skip declaration of $_dependentTables if you use referential integrity constraints in the RDBMS server to implement cascading operations
what should be the case of Postgres. Despite this, I am not able to get it working. Unless I declare the referenceMap (but this shouldn't be needed!), I am still getting error:
No reference from table ... to table ...
The question is - is it possible to use references declared in Postgres in Zend Db, without (re-)declaring them in referenceMap? How - does ZF load it from Postgres to the referenceMap? If so, why I am getting the error?
My reading of the linked documentation is that these two address something different.
The DRI in the db recommendation is a recommendation to specify ON UPDATE CASCADE and ON DELETE CASCADE operations in the db rather than telling Zend to cascade.
What you are doing is something different, which is to use the referential integrity mapping to fetch related rows. In this case, it looks like Zend requires that you declare it.
Related
I wonder if it is possible to do postgres table inheritance in entity framework 7 - instead of the addition of columns do a "real" postgres with base table and table that inherit base table?
If so, how do I configure that?
Cheers,
Mario
This is definitely not supported. In theory you could create your database schema yourself with inheritance (so outside EFCore) and then mapping CLR entities to that, without EFCore knowing anything about the table inheritance. However, if the CLR classes themselves inherit from one another (as they should in general), that would likely trigger EFCore's own inheritance feature, which will mess everything up. If there's some way to tell EFCore to disregard the CLR inheritance you might be able to get away with it.
As for a more complete solution where EFCore is actually aware of PostgreSQL inheritance, that would probably be a pretty big task, which would probably involve changes in EFCore itself (and not just the Npgsql provider).
Can you please open an issue? I definitely won't have any time to work on this anytime soon but it's good to have it in the list.
I'm working on an application that interfaces with a slightly odd database. The design of this database is pretty bad; there are basically no foreign keys (although there are columns that reference other tables, they're not set as keys), columns are named very ambiguously, and the structure does not lend itself to the kind of logic I'm aiming to do (mostly, it forces joins for operations that should be simple, and leaves you trawling through needlessly massive tables for things that could have been split).
Unfortunately, I'm stuck with this database. It's being replicated off a third-party system, so I can't change the table structure or anything. I can add stored procedures and views, though.
In the application, I've come up with a set of classes that I can work with much more easily. I've got quite a bit of experience with Entity Framework, so I'm planning to use that. My initial hunch is that I can add views to the database that return things in the format of my classes, and then from there on out just pretend that they're tables. I've never tried anything like this before, though, and I'm not entirely sure how to proceed.
How can I use Entity Framework to map my classes to these views? Note that it kinda needs to be my POCO classes, rather than anything EF auto-generates - is there a way to tell EF to map existing classes?
If you use code first then Entity Framework will generate CreateTable instructions in the migrations. To use a view instead, replace this code with your own Sql to generate the View. See the answer to this question: Mapping Database Views to EF 5.0 Code First w/Migrations
I would also configure Entity Framework to use stored procedures. Then you can tailor the insert/update/delete sql to match the underlying tables. Again, you can do this by altering the sql that is generated for you in the migrations.
I have some tables which should add to my database every year and name of databases contains the year (like sell2005) and iv'e written some ef queries on these tables ,and queries can only be on a single entity (like sell2005) but what should i do when sell2006 or sell2007 add ? how can i manage them with that single query which iv'e written before?
thank you.
There is no easy way. EF is simply not tool for this scenario. For EF you must have "single table" so you must either use partitioning with one real database table partitioned by year or you must build a view on top of these tables.
The problem is that in EF you have strict relation between classes and tables. You cannot have single class mapped to multiple tables even if they are exactly same (except inheritance which is not solution for you). So the workaround would require to have multiple SSDL/MSL mappings - one for each table and construct correct context instance with correct mapping for every query. As I know dynamic changes of mapping are not possible (except modifying SSDL/MSL files before using them).
We have an application that creates new tables at runtime, but always with the same table schema. The only thing that varies from one of these tables to the next is the table name. Is it possible to access these tables using Entity Framework, specifying which table to access by name?
Entity Framework is not designed for DDL, it's an ORM tool for data access. You would want to use a simple ADO.NET query to create/drop the table.
Creating and dropping tables for every user session will make your log file grow very big very fast. I would consider carefully the reasons you think this is necessary. If the data is temporary, why not save the Session ID in each row and truncate the table on a daily basis?
UPDATE:
No, not really. The Entity Data Model is not dynamic, it's a static XML document that describes the structure of the database. If you want to interact with a table with a dynamic name, you're going to have to stick to "classic" ADO.NET.
With Linq to SQL I guess it would be possible with a stored procedure taking the table Name as a parameter.
A nice post about SP in L2SQL: http://weblogs.asp.net/scottgu/archive/2007/08/16/linq-to-sql-part-6-retrieving-data-using-stored-procedures.aspx
I don't know if that feature exists in EF.
I am building an Entity Framework model for a subset of the Pubs database from microsoft. I am only interested and publishers and books, not publishers and employees, but there is a foreign key constraint between the publishers and emoloyees tables. When I remove the employees entity from my model, the model won't validate because of the foreign key constraint.
How do I create a model for a subset of a database when that subset links to other tabes with foreign key constraints?
Because this is for a demo, I deleted the offending tables and constraints from the database, but this won't work in production.
The correct way to do this is by exposing the foreign key columns as scalar properties. There is a complete explanation, and downloadable sample code, in this blog post. You might find the rest of the post interesting, as well.
You could create views of the pertinent data and bind your model to that. I am not a database expert, but a DBA that I formerly worked with recommended this approach because she said that the view is less intensive on the database server to begin with.
Prior to the release of 3.5 SP1, we built a DAL on top of LINQ to SQL (without DBML mappings, but that is another story) that mapped all of the domain objects to either stored procedures or views. That way, the DBA was happy about the calls following a more set execution plan, as well as being able to encapsulate the database logic outside of the codebase.