I'm persisting a class to MySQL using SORM. This class contains one or two fields that I need on the class but are not to be persisted to the DB. Does anyone know how to exclude these from the table definition?
The problem is that the type of the field is unsupported by SORM. Not a problem, as it's an actor ref and shouldn't be persisted, but there doesn't appear to be a simple way to tell SORM to just ignore it.
Thanks.
There is no way to ignore fields in SORM.
In fact it is a very bad idea from a design perspective to mix a business logic (which an actor ref definitely is) into a model. A model should be just data, nothing else. Even if SORM didn't require that, I would still recommend you to extract the actor-related logic into another object.
Related
I want to have a form where I can add new fields (columns) in an specific entity. Is there a function for this?
Kind regards
Adding a whole column to the table through an HTML form is a weird use case.
If you want to stick to the ORM way of managing the persisted data, you'll have to dynamically add properties to existing entities, which might be a sign of bad schema design.
What I would guess you probably need is an automated way to add this column to your Entity. In such a case I would use the maker bundle.
Supposing that your Entity is called Employee, all you have to do is to type in the following command:
bin/console make:entity
When you'll be asked for the Entity name, enter Employee. The interpreter will tell you that this entity exists and if you want to extend it with news fields, and there you go.
In the (MySQL) database, I'm storing a view hierarchy, with each row in a table referring to a single view. There are several types of views, but they're stored in the same table.
In the application code, each type of view has its own class. Each row in the database instantiates one of these classes.
How should I refer to these classes from the database, so the application knows which class to use?
I can think of several possibilities:
Just specify the class name directly in the table, but this has the disadvantage of having to change lots of rows if the class name changes (which can be done in a single query if required).
Have a separate table storing class names, and use foreign keys to point to the row storing the correct class name. In this case, I could forgo having an ID field in this lookup table and instead have the class name as the primary key and target foreign key, and rely on a cascading UPDATE if the class name changes?
Are there better options available?
If I understand correctly you want to maintain an association between view-names and class-names.
Your bullets suggests, that there can be more than one view for the same class and both of your suggestions would work. The second bullet has the advantage that you can change the class name with a single update. But that doesn't buy you much, because as soon as more than just a single class-name changes, i.e. when the association itself changes, you need to update more than one row.
You might even create a separate table, holding this association. This would be the model for an n:m relationship, which is too general, so you'd have to place a unique constraint on the view-name. Essentially this will just factor out the concern of associating view-names with class-names and allow you to change this mechanism entirely without having to mess with your tables (except the one holding this association).
But actually I would not store any of this stuff in the database
(I also find it irritating that view-names are stored in the database and not in the application logic). The fact that there are class-names, should be of no concern to your database. This is application logic and it should be handled there. So what you need is a way to instantiate an object when the view-name is known. This looks like a classic factory to me. After all, if a class name changes, it is a change in the application code and life is easier, when all resulting changes lie in the application code as well.
I am using Entity Framework to create a Model, I am pretty new to the Entity Framework so bear with me.
I want my database to always be the end all be all of what gets generated, so I dont wnat to make modifications to the model itself. I want to amke all modifications to the database and just hit "Update Model From Database." This has been working swimmingly!
However If I have a one to one relationship between two tables, and I have a foreign key constraint set in the database, I get a navigation property in the child table that goes back to the parent table.
So if I want to access the parent from the child I can do child.parent.fieldName
That sounds great in theory but my issue arises when I need to serialize the object for JSON created by the entity Framework. I always get an error because it tries to serialize the parent object along with the child object. which usually has an invalid state at this point so.. A) it cant be serialized and B) I wouldn't want all that extra info anyway.
Am I misconfiguring the database in some way? is there a way to have the database specify that I only want Parent.Child Navigation properties in the model? and not Child.Parent?
Am I misconfiguring the database in some way? is there a way to have the database specify that I only want Parent.Child Navigation properties in the model? and not Child.Parent?
No. Database knows nothing about your intention to use some tool on top of it. If you don't want the navigation property you must change it in EDMX by deleting it but sometimes you want the property but you also want a serialization. In such case you must either modify strategy used to generate your classes (if you are not using T4 templates it will be quite hard) to use some special attributes dependent on used serialization API to mark some properties as not serialized.
The correct approach is not serializing entities but creating special data transfer objects filled from entities which will contain only properties/data you are going to serialize so you will not get into this problem.
I'm using CodeFirst of EF with a well defined Database.
My Database has a table named 'Centros' (Portuguese word) and I manage to find that EF tries to pluralize my entities to get a 'Centroes' witch is wrong in this case.
If I remove the pluralization modelBuilder.Conventions.Remove<PluralizingTableNameConvention>(); i manage to get it to work BUT I have to rename my table to 'Centro' (to match my entity name).
In Portuguese 'Centro' is singular, 'Centros' is plural.
I don't want to rename my table names so how can I specify the matching table name for my entity after a remove the pluralization convention?
I annotate all my classes, regardless of whether the framework can do it for me through some smart reflection routines. E.g.
[Table("Order")]
public class Order
{
}
We can touch type, it's cleaner and it's less likely to fall over in some unexpected event.
Or you can do one at a time like this in Fluent API:
modelBuilder.Entity().ToTable("ContactInfo");
ModelBuilder is now System.Data.Entity.DbModelBuilder.
I have a LINQ-to-SQL data context in which two tables exist with different names but identical structures. One table (called CallRecords) holds live/current data, and the other (CallRecordsArchive) holds older records - but with the same field names as the live one.
With the basic mapping LINQ to SQL creates two classes CallRecord and CallRecordsArchive - but since they are the same I'd like to avoid this if possible? That way I don't have to write two queries for each instance?
I did consider creating a JOIN view but with millions of rows in both tables it would be a performance nightmare.
The way I've dealt with this is to create an interface for the common aspects of both tables and have both of the generated classes from your data context implement that interface through the use of the a partial class definition. This way when you want to deal with the type as a single concept you can always refer to it as the interface.
try to use inherit for this issue
check this link for more details.
one more
I hope it is help you.