I have a question about Jamie Rumbelow's MY_Model and models generally. MY_Model provides a protected variable that holds the name of the table. I want to use it but I want my model to handle 3 tables. So I guess my question is can a model handle more than one table? is it good practice to do this or is it better to have a model per database table?
By default, MY_Model doesn't support multiple tables, however, you can very easily create methods - I like to call them scopes - to link to other tables in an efficient and elegant manner.
Let's say we have a post_model.php that needs to pull in data from the categories table. I'll assume that we want to bring in our category.name based on the post.category_id.
class Post_model extends MY_Model
{
public function with_category()
{
$this->db->join('categories', 'categories.id = post.category_id', 'left');
$this->db->select('categories.name AS category_name');
return $this;
}
}
We can then use our with_category() method (chained alongside all our built-in MY_Model methods) to pull out our category info:
$this->post_model->with_category()
->get_all();
Or with get_by():
$this->post_model->with_category()
->get_by('status', 'open');
Scoping is a cool way of introducing other tables into your models, while still getting to use all the cool stuff MY_Model provides.
If you wish to use Jamie Rumbelow's MY_Model untouched, you have to use only one table for each model, as it gets the table name from the model name. As he introduced it, this is a base CRUD model, you can extend it to fit your situation.
I think the best practice is to use one table per model (not including the join tables if there are any). Although I sometimes skip this in CodeIgniter if some stuff can be added to the same model logically and are not too big to need their own model. For example there is a comment model and you need votes only for the comments. I do this out of laziness - I hate the manual model loading in CI.
Related
I've been using latestOfmany() for my hasMany() relation to define them as hasOne() for quite a while now. Lately I've been in need of the similar application but for belongsToMany() relationships. Laravel doesn't have this feature unfortunately.
My codebase as follows:
Document
id
upload_date
identifier_code
Person
id
name
DocumentPerson (pivot)
id
person_id
person_id
token
My objective is: define relationship for fetching the first document (according to upload_date) of Person. As you can see it's a many-to-many relationship.
What I have tried so far:
public function firstDocument()
{
return $this->hasOne(DocumentPerson::class)->oldestOfMany('document.upload_date');
//this was my safe bet but oldestOfMany() and ofMany() doesn't allow aggregating on relationship column.
}
public function firstDocument()
{
return $this->belongToMany(Document::class)->oldestOfMany('upload_date')
}
public function firstDocument()
{
return $this->belongToMany(Document::class)->oldest()->limit(1);
}
public function firstDocument()
{
return $this->hasOneThrough(Document::class, DocumentPerson::class, 'id', 'document_id', 'id', 'person_id')->latestOfMany('upload_date');
}
At this point I'm almost positive current relationship base doesn't support something like this, so I'm elaborating alternative methods to solve this. My two choices:
Add a column called first_document_id on Person table, go through that with belongsTo() simple and fast performance-wise. But downside is I'll have to implement so many event-listeners to make sure it is always consistent with actual relationships. What if Document's upload_date is updates etc. (basically database inconsistency)
Add a order column on pivot (document_person) table, which will hold order of related Documents by upload_date. This way I can do hasOne(DocumentPerson::class)->oldestOfMany('order');//or just ofMany() and be done with it. This one also poses the risk of database inconsistency.
It's fair to say I'm at a crossroads here. Any idea and suggestion is welcomed and appreciated. Thank you. Please read the restrictions to prevent suggesting things that are not feasible for my situation.
Restrictions:
(Please)
It should strictly be a relationship. I'll be using it on various places, it definitely has to be relationship so I can eager load and query it. My next objective involves querying by this relationship so it is imperative.
Don't suggest accessors, it won't do well with my case.
Don't suggest collection methods, it needs to be done in query.
Don't suggest ->limit() or ->take() or ->first(), those are prone to cause inconsistent results with eager loading.
Update 1
Q: Why first document of a person has to be a relationship ?
A: Because further down the line I'll be querying it in various different instances. Example queries where it'll be utilized:
Get all the users whose first document (according to upload_date) upload_date between 2022-01-01 and 2022-06-08. (along with 10 other scopes and filters)
Get all the users whose first document (according to upload_date) identifier_code starts with "Lorem" and id bigger than 100.
These are just to name a few, there are many cases where I really gotta query it in various fashions. This is the reason that I desperately need it to be a relationship, so I can query it with ease using Person::whereHas('firstDocument',function($subQuery){ return $subQuery->someScope1()->anotherScope2()->where(...); }
If I only needed to display it, yeah sure eager loading with closure would do well, or even collection methods, or accessors would suffice. But since ability to query it is the need, relationship is of the essence. Keep in mind Person table has around 500k record, hence the need for querying it on the database layer.
Alright here's the solution I've elected to go with (among my choices, explained in the question). I implemented the "adding order column on pivot" table. Because it scales better and is rather flexible compared to other options. It allows for querying the last document, first document, third document etc. Whilst it doesn't even require any aggregate functions (Max, min like ->latestOfMany() applies) which is a performance boost. Given these constraints this solution was the way to go. Here's how I applied it in case someone else is thinking about something similar.
Currently the only noticeable downside to this approach is inability to access any additional pivot data.
Added new column for order:
//migration
$table->unsignedTinyInteger('document_upload_date_order')->nullable()->after('token');
$table->index('document_upload_date_order');//for performance
Person.php (Model)
//... other stuff
public function personalDocuments()
{//my old relationship, which I'll still keep for display/index purposes.
return $this->belongsToMany(Document::class)->withPivot('token')->where('type_slug','personal');
}
//NEW RELATIONSHIP
public function firstDocument()
{//Eloquent relationship, allows for querying and eager loading
return $this->hasOneThrough(
Document::class,
DocumentPerson::class,//pivot class for the pivot table
'person_id',
'id',
'id',
'document_id')
->where('document_upload_date_order',1);//magic here
SomeService.php
public function determineDocumentUploadDateOrders(Person $person){
$sortLogic=[
['upload_date', 'asc'],
['created_at', 'asc'],
];
$documentsOrdered=$person->documents->sortBy($sortLogic)->values();//values() is for re-indexing the array keys
foreach ($documentsOrdered as $index=>$document){
//updating through pivot tables ORM model
DocumentPerson::where('id',$document->pivot->id)->update([
'document_upload_date_order'=>$index+1,
'document_id'=>$document->id,
'person_id'=>$document->pivot->person_id,
]);
}
}
I hooked determineDocumentUploadDateOrders() into various event-listeners and model events so whenever association/disassociation occurs, or upload_date of a document changes I simply call determineDocumentUploadDateOrders() with corresponding Person and this way it is always kept in sync with actual.
Implemented it fully and it is providing consistent results with great performance. Of course it brought a bit of an overhead with keeping it in sync. But nonetheless, It did the job whilst meeting the requirements. Honestly I found this approach far more reliable than some in-official eloquent relationships and similar alternatives.
I have encountered a similar situation years back.
the best workaround on a situation like this is to use #staudenmeir package eager limit
Load the trait use \Staudenmeir\EloquentEagerLimit\HasEagerLimit; on both model (parent and related model)
then try the code below
public function firstDocument() {
return $this->documents()->latest()->limit(1);
}
public function documents() {
return $this->belongsToMany(Document::class);
}
just to add, Eager loading with limit does not work with built laravel eloquent, you would have to build your own raw queries to achieve it which can turn into a nightmare. that eager limit package from staudenmeir should have been merge with laravel source code 😆
Following the official documentation it is very easy to define a relationship between two models. However, One of my models just need to access data from 4 different table in a one to one basis. Those tables will have no functionality. So, I don't want to build a model for them.
For example I can do this,
class User extends Model
{
public function phone()
{
return $this->hasOne('App\Phone');
}
}
Here to complete this relationship successfully I need to have a Phone model. However, if I don't have a model can I use just the table name to define relationship? I want to use something like, return $this->hasOne(DB::table('phones');.
I reckon, if I can somehow use this I will have less models to work with which will make my code more manageable. Is it a good practice?
is there any way to get the defined relationships in eloquent model. I have a situation where I need to get the model relationships so I can update all other eloquent models that relies on a specific id before delete it
There's no unified method to iterate over all registered relationships of a class. You can, however, access all the currently loaded relationships of a model instance (via the ->relations attribute or the getRelations() method), but that's not what you're up to. I'd suggest you take a look at laravel's documentation on inserting and updating relationships. So far that's the best laravel provides out of the box, the rest is developing approaches.
Try this function:
public function getRelations()
You can use
$model->getRelations()
function to get all relations
Also refer below link for details https://laravel.com/api/5.7/Illuminate/Database/Eloquent/Concerns/HasRelationships.html#method_getRelations
I unfortunately need to import data from a third-party vendor and use their non-standard database schema with my laravel project. In addition, I need to store multiple "firms," each with their own set of users in my database.
I'm trying to figure out the best way (if it can be done) to use Eloquent to handle the relationships between these tables. So for instance, with my table structure like this:
BmPerson
'id',
'firmId',
'personId'
BmCoverage
'id',
'firmId',
'personId',
'securityId'
BmSecurity
'id',
'firmId',
'securityId'
... for instance, I need to associate a "BmPerson" with many "BmSecurity" through the "BmCoverage" table.
But I need to somehow use composite keys, because I am storing multiple "firms" in each table (per the 3rd party vendor's database schema).
One approach I've used so far is scoping, e.g.: for my BmCoverage model:
public function scopeFromFirm($query,$firmId){
return $query->where('firmId','=',$firmId);//->where('personId','=',$personId);}
public function scopeFromPerson($query,$personId){
return $query->where('personId','=',$personId);//->where('personId','=',$personId);}
Then I can retrieve the coverage list for an individual person, but I still need to somehow be able to associate the "BmCoverage" with the "BmSecurities." I suppose I could just add a scope the BmSecurities class too, but it would be nicer to just use Eloquent.
Has anyone come up with a good way to use composite keys in laravel model relationships, or should I just stick with the scoping method?
There is a package here that seems to be perfect for your case:
Compoships offers the ability to specify relationships based on two
(or more) columns in Laravel 5's Eloquent. The need to match multiple
columns in the definition of an Eloquent relationship often arises
when working with third party or pre existing schema/database.
You would use it like this:
class BmPerson extends Model
{
use \Awobaz\Compoships\Compoships;
public function bmCoverages()
{
return $this->hasMany('App\BmCoverage', ['firmId', 'personId'], ['firmId', 'personId']);
}
}
If every BmSecurity belongs to exactly one BmCoverage, and every BmCoverage belongs to exactly one BmPerson its probably easier to replace 'firmId', 'personId' with bmperson_id in BmCoverage DB; and 'firmId', 'securityId' with bmcoverage_id in BmSecurity. Then you can use default hasMany relations with one key.
Everything you need for this can be found here https://laravel.com/docs/5.2/eloquent-relationships
You can easily define which cols sohuld be the referenced key.
Example:
public function bmCoverages() {
return $this->hasMany('App\BmCoverage', 'firmId', 'id');
}
This would probably belong to your App\Firm or whatever it is called.
In general the hasMany relations looks like this
return $this->hasMany('App\Comment', 'foreign_key', 'local_key');
As you can see you can specify the keys.
As the others have said, you need to use the HasMany and HasManyThrough relationship.
Here from your table definitions, you simply need access to:
Person->BmCoverage(s)
Person->BmSecurity(s) of an individual.
What I think is the major problem here is linking the BmSecurity with BmCoverage as apparently there's no coverage_id per BmSecurity but rather, a composite mapping through firmId and securityId.
In this case, Laravel does not officially support composite keys unfortunately, although you could use a trait like this... but you could also achieve the same with some tricky hasMany.
i.e. on BmCoverage
$this->hasMany('BmSecurity', 'securityId', 'securityId')
->andWhere('firmId', '=', $this->firmId);
Same applies for BmSecurity from BmPerson using HasManyThrough.
Hope that helps.
read laravel hasManyThrough relationship . it will help you to write this query more easily
https://laravel.com/docs/5.1/eloquent-relationships#has-many-through
I'm writing a custom module for Magento and I need to implement a one-to-many relationship between two tables.
The easyest solution is to create one model for each table and save data separately, but I think this approach has some limitations (I prefer saving data in one single transaction instead of two, I want to load the combined data when I load the collection, ecc).
What is the best way to handle this kind of situation? Is it possible to have one model class that retrieves data from multiple tables?
Thank you
If the 1-n relationship is strictly a data construct rather than an entity construct, then there is no need for a full ORM representation for the adjacent table.
It's often good to find inspiration and examples in the core code, so please refer to the cms/page and cms/block entities, particularly to their resource models. Take the Mage_Cms_Model_Resource_Page::_getLoadSelect() method as an example, as this method is called by the resource model to load data:
protected function _getLoadSelect($field, $value, $object)
{
$select = parent::_getLoadSelect($field, $value, $object);
$storeId = $object->getStoreId();
if ($storeId) {
$select->join(
array('cps' => $this->getTable('cms/page_store')),
$this->getMainTable().'.page_id = `cps`.page_id'
)
->where('is_active=1 AND `cps`.store_id IN (' . Mage_Core_Model_App::ADMIN_STORE_ID . ', ?) ', $storeId)
->order('store_id DESC')
->limit(1);
}
return $select;
}
Note the join, and note that they have one entity table each (cms_page and cms_block) respectively - this is what the ORM expects, by the way - but there are additional tables which contain cms-entity-to-store data. (cms_page_store and cms_block_store). The records in these latter two tables are not represented by their own ORM classes, rather, they are updated, removed, or joined for loads by the cms/page and cms/block models' resource classes.
Again, the deciding factor on whether to handle the SQL through designated ORM classes comes from the business domain - if the records in the 'many' tables represent things which need presentation or complex representation in your business domain, access them through ORM.