Is it possible to have a OneToManyAssociationField as entity extension on for example ProductManufacturer without the ReferenceVersionField in my related custom entity?
If this is not possible, is it possible for the reference version field to have a custom name (so not product_manufacturer_version_id) On first sight, this also does not seem possible.
About the error
I am currently getting the following error when trying to search for manufacturers using $criteria->addAssociation('myCustomEntity'):
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'product_manufacturer.myCustomEntity.product_manufacturer_version_id' in 'field list'
About the big picture
The use case is similar to the SeoUrl entity where there is a ‘foreign_key’ field which can have a relation to multiple entity types. My entity has not associations, but the other entities are extended to have an association to my entity. Just like the SeoUrl.
However, the DAL creates a query which uses the ‘product_manufacturer_version_id’ field, which does not exist on my custom entity…
Is it possible to have a OneToManyAssociationField as entity extension on for example ProductManufacturer without the ReferenceVersionField in my related custom entity?
No, you must set a ReferenceVersionField when adding associations to the definition of a versionized entity. This is too deeply rooted in the basic principles of the data abstraction layer to work around.
If this is not possible, is it possible for the reference version field to have a custom name (so not product_manufacturer_version_id) On first sight, this also does not seem possible.
You can change the storage name of the field. That is the name of the corresponding column within your database table. When you instantiate ReferenceVersionField you can use the second, optional argument to provide the storage name:
public function __construct(string $definition, ?string $storageName = null)
The storage name should be provided in snake case. The name of the object property for the field will then be derived from the storage name and converted to camel case. So given you provide my_version_custom_id for the storage name, the object property of the entity will be myVersionCustomId.
Your entity may have multiple associations to different entities, but if those entities are versionized your foreign key constraint has to be a combination of columns for both the foreign primary key as well as the foreign version id.
Related
See Problem Image
If UserCreationAttribute is created by Omiting one field in UserAttribute Why we using
both in that Arrow and what does it mean I'm confused.
The first generic parameter UserAttribute is used to control what fields can be in the model and the second one UserCreationAttribute is used to validate a set of fields while creating an instance of this model. Usually a primary key field is omitted from creation attributes because it's auto generated. You should add all optional fields there along with the PK field that are not needed if you create a model instance.
It's your responsibility to define creation attributes as a subset of all attributes that's why it's recommended to use Optional with attributes.
I am making a class diagram for Class/Course Registration where students have to first register their course then select their class schedules (timetable)
I am unsure if I can have CourseRegistration and ClassRegistration table like that. The reason why I made it like that is, a student can register for a course but doesnt register to a class directly. so they can wait few days and then only register. So I have to make sure the course registration is saved in the database.
Thank you for all the help
PS: pls don't mind my attributes, they're just a draft.
Your business logic for the registration process (register both for a course and a corresponding class) is too complicated. Normally, one would only register for a class, which would then imply taking the corresponding course.
Also, what does "ClassSchedule" stand for? Is an instance of a "ClassSchedule" a class meeting?
Since your model is supposed to define a design (of database tables and of, e.g., Java classes), each entity class should have an ID attribute defined, which is expressed in UML with the keyword "id" in curly braces appended to the attribute declaration. Having "ID" in the attribute names is not a formal declaration. Also, an ID attribute seems to be missing for ClassSchedule.
Yes, that's fine this way. You could alternatively use the association class notation like this:
Some side notes:
labeling associations is not that helpful except you are on a business level analysis. Rather use role names on either end where appropriate.
Edit I somehow overlooked that you're designing tables. So my previous comment
remove all the id attributes. Each object will have its unique id assigned by the runtime system. Use such an id only if it's of public meaning (e.g. a passport id or a student's registration number). And then use that specific name (e.g. passportId) rather than a <class>id.
goes just for basic class design. If you already have a (derived) table design you can just go with those ids.
I have sample project for identity customization using
Install-Package Microsoft.AspNet.Identity.Samples -pre
command. But, for this project I have a general ApplicationUser class representing all the users of my application. What if I have different categories of users. For example, I may have Teacher and Student entities and data representing both the entities will be different. How can I customize my application to store data for both the entities having all the features of ApplicationUser?
One way that I think is inheriting both the classes from ApplicationUser and then doing appropriate changes in IdentityConfig.csand defining Controllers for each of them. Is there any other efficient way of doing this?
What if I want to use the built-in authentication and authorization features but using database first workflow?
First, you want to know how to create "types" of users. The way you would do that is exactly how you expected: inherit from ApplicationUser. By default, this will result in a single "users" table with an additional Discriminator column. This column will store the class type that was persisted, i.e. "Teacher", "Student", or "ApplicationUser", and EF will utilize this information to new up the right class for each particular record.
One thing to note with this, though, is that you need to be aware of how UserManager works, namely that it's a generic class (UserManager<TUser>). The default AccountController implementation you have from the sample defines a UserManager property on the controller which is an instance of UserManager<ApplicationUser>. If you use this instance with something like Teacher, it will be upcast to ApplicationUser. In particular if you were to do something like UserManager.Create(teacher), it will actually save an ApplicationUser, instead (the Discriminator column's value will be "ApplicationUser", rather than "Teacher"). If you need to work with the derived user types, you'll need to create separate instances of UserManager<Teacher> and UserManager<Student> for that purpose.
Next, you want to know if you can use a "database first workflow". To answer that, we need to define exactly what that means. EF has what it calls "Database First" which employs EDMX to represent your database entities. This in particular is incompatible with Identity. However, despite the name, what EF calls "Code First", can work with an existing database just as well as create a new one. In other words, yes, you can use an existing database, if you prefer, but no you cannot use "Database First", in the EF-sense. For more information about using an existing database with Code First, see my post.
I am trying to create an association between 2 linq to sql entities, say Entity A and Entity B.
A uses a non-column attribute property ( named BaseDocumentType ) and a column attribute in an Association for "ThisKey" and 2 column attributes for "OtherKey". The following is an example of my Association attribute definition...
[System.Data.Linq.Mapping.AssociationAttribute ( ... ThisKey = "BaseDocumentType, Column2" , OtherKey = "Column1,Column2" )]
When I run it I get the following error...
"Data member 'System.String BaseDocumentType' of type 'Library' is not part of the mapping for type 'A'. Is the member above the root of an inheritance hierarchy?"
How can I define the relationship using the non-column attribute property or how do I make this work?
Thanks.
The message is quite clear. LINQ to SQL translates statements to SQL and you tried to use a property that doesn't map to a column, so it can't be translated to SQL.
You'll have to retrieve the entities you want from the database then try to query them using LINQ to Objects, ie LINQ operations on the resulting lists or arrays. A better option is to rethink your design and find a way to retrieve only the data you need from the database and avoid processing the results on the client.
Linq to SQL in this case prevented you from doing something really dangerous. It could have retrieved all the data and process them using your non-column attribute but that would create an enormous performance hit. Some naive LINQ providers actually do just that. Imagine retrieving 1000 objects from the database only to find the two objects that match over this non-column attribute.
I'm developing a new application which is based on a legacy database. The old legacy database does not use reference integrity and first we try to not change the existing schema. I still want to be be able to use navigation properties in my EF generated POCO classes.
However, the old data model has one big issue regarding child-parent relationships: the column in the child table is referencing the parent table via the uniqe key of the parent, not via the primary key of the parent table. Is it still possible to generate such associations?
I tried to mark the unique key in the parent table as "entity key" but then I still need to provide a mapping for the parent table's primary key which I am not able to because there is no mapping for it available, this primary is just a dummy "counter". If I do not provide a mapping for the primary key, I get
"Error 111: Properties referred by the Principal Role XXX must be exactly identical to the key of the EntityType YYY referred to by the Principal Role in the relationship constraint for Relationship ZZZ. Make sure all the key properties are specified in the Principal Role"
No EF does not support unique keys at all. It is hopefully planned feature of the next major release.