I want to add a new column to Language tables but unlike other models (User, Role,...) I could not find the Language model classes in the solution.
I tried to create a new model (MyLanguages) inherited from ApplicationLanguage but it is a bad way because I have to do many things. So what is the best way to do it?
There's no easy way of achieving this issue. like you said, it's not same as User/Role entity. You can create a new entity called MyLanguage and inherit from Language. After that you'll have a Discriminator column. Add a migration to update all existing languages to MyLanguage in discriminator column. Then you have to write custom code to update a new added language to MyLanguage.
https://aspnetzero.com/Documents/Extending-Existing-Entities
Related
I have a Laravel 8 application and am wondering how to solve the problem of how to solve a typical polymorphic issue. I have an Employee model. That Employee can be an ExecutiveEmployee or EntryLevelEmployee. There will be methods an ExecutiveEmployee has that an EntryLevelEmployee doesn't have and the inverse is also true.
Using Laravel 8, is it right to create a base Employee model (without a corresponding table?) and then create two models named ExecutiveEmployee and EntryLevelEmployee that inherit from Employee? This would also imply that both employee types will have two different database tables, even though there will be a lot of overlapping data.
Does it make sense to just have one Employee model and create a migration that has the employee type listed in the model? I am assuming that it's ok if an EntryLevelEmployee has some database attributes which are relevant to it that may or may not be relevant to an ExecutiveEmployee type here, or is that an incorrect assumption?
What's the correct way to model this in Laravel 8? I prefer to keep everything in one table because of how similar the models are. I do have to keep in mind that there will be data that one has that the other doesn't. There will be different accessor methods as well.
Is it possible to have everything in one employees table while utilizing multiple models? Meaning, if I create two models named ExecutiveEmployee and EntryLevelEmployee they would both query the underlying table employees?
UPDATE 1
The more I research, the more I think polymorphism is the incorrect approach here and what I might need is Single-Table Inheritance. This package seems to bring the capability to Eloquent. Would there be a good reason to not use this?
I would use polymorphic relationships in this case, because you are more flexible and have less coupling.
Using the Single Table Inheritance (STI), you can add type specific columns in the employees table and make them nullable. But think about adding/removing types in the future.
executive_employees
id - integer
executive_specific - string
entry_level_employees
id - integer
entry_level_specific - string
employees
id - integer
name - string
email - string
employable_id - integer
employable_type - string
As for the STI the same would be
employees
id - integer
name - string
email - string
type - string
executive_specific - nullable string
entry_level_specific - nullable string
So STI would be suitable when you don't have type specific columns. But you want to add specific behavior in your code. For example a User type (Admin, Author).
Even so, it's a matter of preferences.
It really depends on the state and behavior of your employee object.
Below are few points I will consider to make a decision
If your objects' states/properties are different then definitely you will create different models as your data will be stored in different tables.
If most states/properties are same and some are different, you can
consider storing all in one table/model and for the difference in
behavior create separate table like Ron Van Der Heijden has
suggested and you can consider query scope with that to make
transaction with database.
And another view will be
How many JOINs you will create if you will create different tables,
will that impact the performance and other stuffs, will it make your
code complex?
Can you make simpler relations and handle stuffs independently?
When you are making an API, will your
code make the api overworking? or you need to create too many request
for any operation?
These stuffs will decide how you will make a decision.
Update 1:
Another point I would like to add about the package you are thinking to use, consider using a parent key in table and you can define relationships in a single model.I do not think you need to use a package, you can define it yourself, I guess.
I don't understand why you don't create a simple one-to-many relation. Based on the information you provided, the polymorphic relation looks unnecessary. I think the right way is to create employee_roles table and relations. Then you can give different permissions to different employee types. There are several ways to do that. You can create a middleware to create route restrictions. You can check the role before executing a function in the controller, and run only if the employee has permission. You can use if-else in blade not to render the parts that can't be used by auth user etc.
If you have different “types” of employees, and each employee type should have different logic then yeah, that sounds like a polymorphic relationship.
I found many results how to create migration from a model, but is there any way to create a model from migrations?
Basically I want to give a table name, and if there is multiple migration files (one to create and others to update the previous states) the model could be updated.
Is there any solution for this?
I'm not sure that there's a good way to create a model directly from migrations, as it depends on what database you use as to the exact structure of your tables.
There seems to be a package which support generating the models from your database, however:
https://github.com/laracademy/generators
Being new to app design and coding I have the following question related to Class design. I have a class by the name of Art Object which has the following other attributes:
'Type' such as 'Painting', 'Sculpture', 'Drawing', 'Collage' etc.
Categories such as 'Modern (Art Nouveau)', 'Art Deco', 'Gothic' etc.
Now my question is, how do I design this. In my opinion I have two options:
Create a separate model , say ArtObjectTypes and have all the CRUD operations. And then establish relation between ArtObject and ArtObjectType.
Create a separate model , say CustomFields on which I can have all CRUD operations. The benefit in this case is that in future I will be able to generate more custom types attach with the ArtObject or any other Object.
Please advise which of the above options I should go for and why. Also, please do bring up if there is another choice.
First ask yourself how you would organize this in your database.
Draw a schema like this:
Define the relations, the foreign keys, and only then you should start implementing the models. A model in laravel corresponds to a table in your database.
My intent is to create a generic (not in C# meaning) database model for Windows Phone using linq to sql. User of such model should be able to pass an array of his data object types (classes marked with Table attribute) to model's contstructor, and then model should take care about adding related tables to database and provide API for CRUD operations.
But then I've found out that in order to add tables to database, your data context (class inherited from DataContext class) have to declare each table as a property! That's embarrassing. Does this fact mean that my idea is not implementable? Because I obviously cannot add properties to my DataContext-based in the runtime.
So my question is, am I right in my judgments? If yes, are there some workarounds to solve this issue?
Thanks in advance.
EDIT: better question tagging, for somebody finally notice this.
You do not need to use a strongly typed DataContext (a class inheriting from DataContext and declaring properties for each table). You can do something like the following instead
var context = new DataContext("connection string", new AttributeMappingSource());
var table = context.GetTable<T>();
where T is some type marked with the Table attribute.
I am working on a MVC3 code first web application and after I showed the first version to my bosses, they suggested they will need a 'spare' (spare like in something that's not yet defined and we will use it just in case we will need it) attribute in the Employee model.
My intention is to find a way to give them the ability to add as many attributes to the models as they will need. Obviously I don't want them to get their hands on the code and modify it, then deploy it again (I know I didn't mention about the database, that will be another problem). I want a solution that has the ability to add new attributes 'on the fly'.
Do any of you had similar requests and if you had what solution did you find/implement?
I haven't had such a request, but I can imagine a way to get what you want.
I assume you use the Entity Framework, because of your tag.
Let's say we have a class Employee that we want to be extendable. We can give this class a dictionary of strings where the key-type is string, too. Then you can easily add more properties to every employee.
For saving this structure to the database you would need two tables. One that holds the employees and one that holds the properties. Where the properties-table has a foreign-key targeting the employee-table.
Or as suggested in this Q&A (EF Code First - Map Dictionary or custom type as an nvarchar): you can save the contents of the dictionary as XML in one column of the employee table.
This is only one suggestion and it would be nice to know how you solved this.