a customer has an existing database. The schema is often changed within the database itself (e.g. he adds a new column).
My task is to develop an admin area with symfony that automatically reacts on table schema changes without modifying the application code. E.g. the customer adds a new column to table "MyEntity", and the application automatically generates a new column in the accordingly list view.
My approach is to dynamically map the table columns to the Entity class so that ALL Attributes and ALL Getters/Setters are generated dynamically from the table schema.
So is it possible to map the table columns in a Doctrine Entity without the use of Annotations or XML Files.
Something like:
class MyEntity{
public function generateMappingFromSchema($sTableName){...}
}
Please don't do that. Doctrine was not designed for such use case.
There is a library though you should check https://github.com/laravel-doctrine/fluent which basically is a mapping driver that allows you to manage your mappings in an Object Oriented approach. And there are other tools:
http://crud-admin-generator.com/
http://crudkit.com/
http://www.grocerycrud.com/
which are maybe better for that, I don't know.
But again, please don't do that. Do not allow the customer to modify the database schema or give them e.g. a phpMyAdmin which was designed for that.
Related
I followed this question to create timestamps that save on create and update maintained by the database: Doctrine2 - Type timestamp - Default value
Problem is that now I get a "value cannot be null" when saving a record using Doctrine. I see in the generated insert that it's trying to save the timestamps as null. Is there a way to avoid Doctrine setting a column on INSERT/UPDATE.
Why do you want letting DB to do Doctrine job?
Doctrine won't set a column at all, if you don't map it. But would you take a look to Timestampable extension?
Another approach is using Doctrine entity listeners. So you can make your own, on PrePersist and PreUpdate and set the time there.
If you're worrying about setters for changing dates, you can at least use dynamic mapping for that fields (just map datetime properties on-the-fly when you really need to change them). Not sure that you can use reflection though, because your entity can be behind the proxy class.
If you still want keeping business-logic in Database, you can map only fields you really want to change (not datetime fields in your case), then write custom Doctrine hydrator (just extend their AbstractHydrator class) that will populate all the fields you need (include datetime). Also you can configure your new hydrator as default (i.e. in Doctrine configuration section in config.yml), so it will work without any adjustments.
I want to restrict creating or modifying the data model schema for backendless. Specifically, only want to create or modify the data model schema using the console. The data model schema should not be modified using the API.
How can this be achieved?
It this point it can be achieved by you making sure that your code stays consistent and does not introduce new fields/properties. Adding a new field to a class and then saving an instance of the class with the API will result in a new column being created. So to avoid that make sure that your classes at any point of time represent the schema of the backend.
Let's say I have a Setting entity with some fields like IntValue, dateValue, stringValue and some linked entities, like countries (ManyToMany to entity Country), languages (ManyToMany to Language) etc.
Settings are created by users and assigned to specific objects (not important here, but I wanted to clarify).
Now I suddenly need to have UserDefaultSetting, which will be the same, but with additional user field (ManyToOne to User entity).
I tried to extend existing Setting entity class with one more field added. The problem is, as I looked at the schema update SQL, it created new table for the new entity, but without all the tables needed to ORM connections (mostly ManyToMany). Just one table with "scalar" fields.
So previously I've had setting table with int_value, date_value etc. but also setting_country and setting_language tables, linking ManyToMany relations. After creating child entity, Doctrine created only user_default_setting table with int_value, date_value etc. and additionally user_id column, but I can't see any relation/link tables.
I know I should've been do it with abstract base entity class, but at the time I started, I didn't know that and now part of the project is on production (don't look at me like that, I blame the client) and I don't want to change that "base" class now. Can I inherit everything from non-abstract entity class in a way it will work?
UPDATE: everything explained. See Cerad's comment. Thanks!
I have a table in another database I would like to scaffold via ASP.NET Dynamic Data and incorporate into my existing Entity Model - is there anyway to do this? (eg using a view or other mechanism or customize the view, edit or insert operations via ad-hoc SQL or stored procedures?)
I don't want to replicate the entire DynamicData sub-folder structure and create another entity model for just one table
I was able to solve this by manually creating an entity in the SSDL and CSDL sections of the .edmx file by using a DefiningQuery and then defining the EntitySets for my entity class
I also added insert / update / delete Function elements to the SSDL with inline SQL using the CommandText property
At this point I had enough to let the Designer map the CRUD methods to these inline SQL functions I defined
It's a little tricky but it works and the general approach opens up many possibilities I had not thought about
How do I define a database view using Entity Framework 4 Code-First? I can't find anything about this anywhere!
That's because you cannot define database view using code-first approach. Database view is database construct which uses SQL Query on top of existing tables / functions. You can't define such constructs using code first.
If you want view you must create it manually by executing CREATE VIEW SQL script for example in custom initializer - it will be similar like this answer. Just be aware that this will not help you if you want to map entity to a view. In such case you would probably have to first drop table created by EF and create view with the same name (I didn't try it but it could do the trick). Also be aware that not every view is udpatable so you will most probably get read only entity.
To do a view you create the model, then in the initializer you run the SQL statement to create the view directly against the context with the first line of code, and then in the context you override OnModelCreating and run the second line of code to ignore the model.
context.Database.ExecuteSqlCommand(Resources.<resourcename>);
modelBuilder.Ignore<modeltype>();