checklist = model("user_checklist").findAll(include="tb_machine_checklist");
Above is the query I am using to fetch records from a table called user_checklist and it is related to table called tb_machine_checklist.
Now there is a table called "tb_machine_checklist", however it it gives me an error saying;
The "tb_machine_checklists" table could not be found in the database.
Why is the "s" being added when I didn't specify?
Be sure to read the chapter in the documentation about Conventions.
CFWheels adopts a Rails-style naming conventions for database tables and model files. Think of a database table as a collection of model objects; therefore, it is named with a plural name. Think of a model object as a representation of a single record from the database table; therefore, it is named with a singular word.
Fortunately, CFWheels lets you override most conventions with a little bit of extra code.
In your tb_machine_checklist model's init method, add this line of code:
<cffunction name="init">
<cfset table("tb_machine_checklist")>
</cffunction>
Then any queries that CFWheels writes for you will use your singular table name instead of the conventional plural one.
I guess the include in findAll specifies the model name, not the table Name. Wheels ORM pluralizes in some occasions the model Name and maps it to the table Name. Maybe you could explicitely set the table name for the model in the model?
I solve this matter, My models were not named the same as my database tables. and once that was done properly, this problem went away.
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 just created a model called GrupoInstructor, the table's name is grupoinstructor
When I want to create a query for that model it shows "base table grupo_instructors doesn't exist". Why is that? why laravel adds a _ to the table's name?
Is there a way to tell lavarel that my table's name is grupoinstructor? I just realized that have some errors in my previous migrations so my last one doesn't rollback...
Thanks in advance.
In your model you can override the name of your table to suit your needs
protected $table = 'grupoinstructor';
Laravel and most of the frameworks assume that capital letters are used for separation hence the reason why it expects your table name to be called grupo_instructor which in my mind is more readable way anyway instead of concatenating the words together.
I'm currently watching the Laravel Tutorial Episode 7
https://laracasts.com/series/laravel-from-scratch-2017/episodes/7
I created the database and populated its data on the previous episode,
it is only this time, the tutorial introduces model, upon creating the model name "Task" via php artisan make:model Task, it automatically connects to my table "tasks" without any clue how it happened.
So how did a freshly out of the box model knows it?
It's general definition standard.
If you create a table with plural name and create model for this table as singular, then model automatically connects corresponding table, otherwise you should define table name in model like:
protected $table = 'task_table';
It's a convention Laravel follows. Laravel will search for a table that is the snake cased Model's name in plural unless you indicate another table.
If you generate the model with the migration flag (e.g. php artisan make:model Task --migration), it will also create a table with the model's name in plural automatically (in this case, Tasks).
You can check more about it in the documentation.
Table Names
Note that we did not tell Eloquent which table to use for our Flight
model. By convention, the "snake case", plural name of the class will
be used as the table name unless another name is explicitly specified.
So, in this case, Eloquent will assume the Flight model stores records
in the flights table. You may specify a custom table by defining a
table property on your model (...)
In my database schema, I have multiple tables that hold generic data for objects, for instance I have a user table and a user_data, post table and post_data, and so. these *_data tables all hold a foreign key to the object and a pair of key-value. now in my laravel models I would like to have a single data models for these tables (rather than a model for every single one) and represent the has_many relation in a dynamic way where somehow I can define the table name according to the parent model. I think the parent model would have something like:
return $this->hasMany('data');
but I don't know how to express the inverse relation nor how to tell laravel which *_data table to use. so my question is, is it possible? and if so, how?
You have two options.
Either create a model for each data_* table and use the relation as stated with $this->hasMany('data'); and $this->belongsTo('User'); in the data table and the user table.
Or you can use Polymorphic relations, I personally prefer the polymorphic relations solution, more neat.
I am just getting into Entity Framework for the first time beyond simple examples.
I am using the model-first approach and am querying the data source with LINQ-to-Entities.
I have created an entity model that I am exposing as an OData service against a database where I do not control the schema. In my model, I have two entities that are based off of two views in this database. I've created an association between the two entities. Both views have a column with the same name.
I am getting the error:
Ambiguous column name 'columnname'. Could not use view or function 'viewname' because of binding errors.
If I was writing the SQL statement myself, I'd qualify one of the column names with an alias to prevent this issue. EF apparently isn't doing that. How do I fix this, short of changing the view? (which I cannot do) I think this does have something to do with these entities being mapped to views, instead of being mapped to actual tables.
Assuming you can change the model have you tried going into the model and just changing one of the column names? I can still see how it might be problematic if the two views are pulling back the same column from the same table. I can tell that when working directly with a model mapped to tables, having identically named columns is not a problem. Even having multiple associations to the same table is handled correctly, the Navigation Properties are automatically given unique names. Depending on which version of EF you used you should be able to dig into the cs file either under the model or under the t4 template file and see what's going on. Then you can always create a partial class to bend it to your will.