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.
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.
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.
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've been using a custom base class with an id property that is automatically assigned by a manager class when an instance is created. I use this value in multiple ways and require it to differentiate each instance.
I want to remove the need for my own base class but still have a way to tell instances throughout my application apart.
Is there a property set on all objects in ActionScript 3 that can act as a unique identifier?
Nope, there aren't any built-in unique IDs like this. What you're doing sounds like the right way to go if you need to track objects. (You can differentiate objects with the === operator - that is, you can tell whether two references point to the same object or not. But I gather that's not all you need.)
I'm creating a .dbml file from a database. My "property" table has foreign keys to the "county" table and to a "propertysource" table.
When code is generated, Property.Source is defined as a PropertySource type, but Property.County is defined as an int, instead of a County type.
I'm afraid I don't have the experience with LINQ to SQL to understand what's happening here or why that is or how to fix it. I can't find anything obvious about my schema that might cause this. How can I get the automagically generated code to recognize the County property of the Property object is a County type?
When you click on the Property in the DBML file, you can modify it's Type using the Properties window. In the Properties window, there's a field for Type. You can select some of the standard Types from the dropdown, or enter in your own custom Type using it's full name, ie. "MyProject.Location.Country.CountryType", etc.
Be sure to rebuild your project before you try to access this in IntelliSense. Hope this helps!
When you open the dbml designer make sure you have a diagram that shows two arrows from the Property class: one arrow going to the County class, and another going to the PropertySource class. Also, you should have those three classes in your designer as well.
If you don't see the object model that way then there is probably something wrong with the way your database schema is set up.
I would check to make sure your foreign keys are set up correctly.