I've got an uploads controller which handles video file formats. In the uploads controller you are able to browse all the videos uploaded and watch them. In the function watch I have a comments element which updates the comments table with the userid (comment left by user that is currently logged in) uploadid (uploaded that is currently being watched) and the comment (comment of the user).
I've got the form working perfectly, however I'm not to sure how I would acquire the information from the comments table, such as the necessary query to be implemented?
Any suggestions?
I saw your other post CakePHP Elements not updating table, so I sort of have an idea of your situation. It seems you are representing comments with your Post model.
You want to query data from your Post model, in your UploadsController, correct?
If your comments table is named comments, you need to ensure it is associated to your Post model. Cake automatically associates Models and database tables if they follow Cake's naming conventions. But if they are in fact different, you can specify a custom database table for your Post model:
<?php
class Post extends AppModel {
var $useTable = "comments" /*Or whatever you named your comments table*/
...
}
?>
You also have to ensure the model associations are set up between Post and Upload:
Post belongsTo Upload
Upload hasMany Post
I noticed you have:
Post belongsTo Upload
Upload hasAndBelongsToMany Post
Is there a reason why it is HABTM? HABTM implies that the same Post can belong to many different Uploads. hasMany implies that a Post can only belong to a single Upload.
Finally, now that the model associations are set up, you can access related models in a controller:
<?php
class UploadsController extends AppController {
...
function watch ($id = null) {
$this->Upload->id = $id;
$this->set('uploads', $this->Upload->read());
/* To get related comments (Posts) */
$related_comments = $this->Upload->Post->find('all', array(
'conditions' => array(
'Upload.id' => $id /* This condition makes it so only associated comments are found */
)
));
$this->set('comments', $related_comments);
}
...
}
?>
Related
I have one table named "files" which I would like to contain all my users files.
The files can be uploaded from different views and should be related to different tables: questions table, answers table, comments table, messages table etc... but still, all of them will be related also to users table, that way I will know who is the owner of the file.
Example: "user asking a question, and attaching a picture to help other users understand the question more easily."
The question values goes into 'questions_table', the file goes to 'files_table', and the user ID also goes to 'files_table'.
The question is! (sorry for the long introduction):
Should I use a pivot table? or just a double one-to-many relation from 1.'users_table' to 'files_table' & 2.from 'question_table' to 'files_table'?
I think this is the perfect use case for a Polymorphic Relationship.
Here is the structure of the tables:
users
- id
- name
questions
- id
- title
files
- id
- user_id
- filable_id
- filable_type
In the files table, you can see a filable_id field that is going to reference either a question id, answer id, comment id. And the filable_type that is going to tell the record which object is associated with this file.
class Question extends Model
{
/**
* Get all of the question's files.
*/
public function files()
{
return $this->morphMany('App\File', 'filable');
}
}
class File extends Model
{
/**
* Get all of the owning filable models.
*/
public function filable()
{
return $this->morphTo();
}
}
I highly encourage you to learn more about this type of relationship on the Laravel Documentation
I have created a custom push() method which saves all model's relations in cascading manner and collects full snapshot of entity and children details for audit log.
Everything works fine with belongsTo and hasMany relations. I just do as follows:
$ae->target()->associate(new AuditableEntryTarget(["name" => "single target"]));
$ae->children->add(new AuditableEntryChild(["name" => "one of children"]));
$ae->children->add(new AuditableEntryChild(["name" => "two of children"]));
// add grandchildren to the first child
$ae->children[0]->children->add(new AuditableEntrySubChild(["name" => "one of subchildren for first child"]));
// add target subchild
$ae->target->subtarget()->associate(new AuditableEntryTargetChild(["name" => "single target child"]));
// my custom method which saves and collects to audit log all the children, no matter if they are attached through hasMany or belongsTo
$ae->push();
But the problem is with hasOne relation. It does not offer any way to attach the related model to my root model without saving it first. HasOne relation has only save() method in Laravel:
/**
* Attach a model instance to the parent model.
*
* #param \Illuminate\Database\Eloquent\Model $model
* #return \Illuminate\Database\Eloquent\Model
*/
public function save(Model $model)
{
$model->setAttribute($this->getPlainForeignKey(), $this->getParentKey());
return $model->save() ? $model : false;
}
which, as you see, not only associates, but also saves the model. To be able to detect all changes for fields, my method requires that the relations are attached to the model but not saved yet because else I won't be able to intercept the save process and attach the data to my snapshot. BelongsTo has associate and hasMany has add for attaching models without saving them yet, but I cannot find anything similar for hasOne.
Is there any way to attach a new model instance to hasOne relation without causing it to be saved immediately (something like associate for belongsTo or add for hasMany)?
With help of Laracasts guys, the workaround seems to be
$model->setRelation('child', $childInstance);
Still, it's strange that Laravel does not initialize hasOne relationship the same way as it inits hasMany.
I'm trying to get my head around using polymorphic relationships for a many-to-many relationship between suppliers and products:
products
id
name
suppliers
id
name
product_supplier
id
product_id // belongsToMany easily takes care of this id
supplier_id // and this id
price // this can be fetched using withPivot('price')
deliverymethod_id // I'm having difficulties "joining" this one.
I'm confident in using belongsToMany(), I can easily do something like this:
public function products()
{
return $this
->belongsToMany('Supplier')
->withPivot('price');
}
But the catch here is joining to that third column in the relationship table:
deliverymethods
id
name
I am unsure how to do this. I've been told that Polymorphic Relationships are what I'm after however I'm unsure how to implement them for my situation.
http://laravel.com/docs/4.2/eloquent#many-to-many-polymorphic-relations
According to the documentation, I would have to rename my table columns to include *able_id and *able_type. This is really confusing.
I was expecting laravel to having something like belongsToMany('Supplier')->withAlso('Deliverymethod')
I'm afraid that method does not exist (yet?).
What I fall back to is manually filling in the 3rd relation:
public function products()
{
return $this
->belongsToMany('Supplier')
->withPivot('price', 'delivermethod_id');
}
Now I can access ->pivot->deliverymethod_id on every Product that I get via Supplier.
You could even add a function in your Product model that fills this in automatically:
Class Product ... {
protected $appends = array('deliverymethod');
public function getDeliverymethodAttribute()
{
return Deliverymethod::find($this->pivot->delivermethod_id);
}
Now every time you request a product via it's relation to the supplier, it automatically includes a deliverymethod attribute with the object in it.
(To have it not throw an error when you get a Product directly, just remove the $appends variable from the Product model and call the getDeliverymethodAttribute() method manually whenever you need it.)
Short explanation about polymorphic relations:
Polymorphic relations are for relations, where two models are related to a third model at the same time. So for example both a User and a Product can have a Picture of them. Now, it doesn't make sense to have two models for the pictures (UserPicture and ProductPicture), since they both have the same characteristics. This would be a perfect reason to use a polymorphic relation, where the Picture can both belong to a User or a Product.
However, in your case the Deliverymethod applies directly to the relation between Supplier and Product. So this is not where polymorphic relations would work, but it has instead to be done the way you did it.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I need to develop a custom form generator using Laravel.
That means there will be a GUI to select and customise the forms like Registration Form or Booking Form.User should be able to add/edit/delete different form controls, define it as mandatory, etc.
Here I am little confused to handle this in back-end. What is the better way to achieve this?
Or how can I implement a database architecture to use some metadata table which can be used to handle multiple items like Wordpress and is there any built-in Laravel functionalities to handle these meta objects?
And how the insert/update/delete handled in this metadata approach?
Here an insert should have only one row in the meta table. Suppose at the time of user registration, without saving the firstname and lastname in separate rows in the meta table, it should use some objects like this in a single row.
a:3:{s:9:"firstname";s:10:"irshad.far";s:8:"lastname";s:0:"";s:5:"_meta";a:7:{s:2:"ip";s:10:"14.99.80.3";s:9:"confirmip";s:10:"14.99.80.3";s:11:"confirmtime";d:1407932201;s:8:"signupip";s:10:"14.99.80.3";s:10:"signuptime";d:1407932201;s:4:"lang";s:2:"en";s:4:"form";s:7:"unknown";}}
Handling a table of meta data is fairly straight forward using Laravel's Eloquent relations. Let's say you have a users table in your database that contains:
id email password created_at updated_at deleted_at
If you want to keep it simple and not add all sorts of extra data to your users table you could create a meta table and then a link table user_meta to relate the two.
But what if you also have a posts table (as with Wordpress) and your posts also need meta data? Instead of also creating a posts_meta table to link your posts to their meta, we can use Laravels Eloquent relations and create some Polymorphic Relations.
The Database
Here's our setup, along with our users table (above) we have a posts table which has the fields:
id title content created_at updated_at deleted_at
We also have our meta table that follows the guidelines for a polymorphic relation:
id name value metable_id metable_type
//int meta key meta value post/user id resource ie post/user
Using this we could add meta for a post or user to our meta table like this:
id name value metable_id metable_type
------------------------------------------------------
1 nickname Steve 1 User
2 author Steve O 1 Post
All we need to do to grab this info from the database is define the relations in our respective models.
The Models
So now we have our DB ready we need to setup our models (one model for User, one for Post and one for Meta) with our polymorphic relationship. Our User and Post models are both going to use the same function to relate to our Meta model:
User.php
========================================
class User extends Eloquent {
public function meta()
{
return $this->morphMany('Meta', 'metable');
}
}
Post.php
========================================
class Post extends Eloquent {
public function meta()
{
return $this->morphMany('Meta', 'metable');
}
}
Now we define the inverse of those relations in our meta model:
Meta.php
========================================
class Meta extends Eloquent {
public function metable()
{
return $this->morphTo();
}
}
That's it!
Getting the data
Now all you need to do to get at the meta data for a user or post is:
// Load in a post with an id of 1 and get all it's related meta
$post = Post::find(1);
$meta = $post->meta;
If we were to return the meta object we might see something like:
[{"id":2,"metable_id":1,"metable_type":"Post","name":"author","value":"Steve O"}]
Onwards!
From here you can create helper functions like this one that checks if the meta you're after exists in the results:
public function hasMeta($key)
{
$meta = $this->meta;
foreach ($meta as $item):
if( $item->name == $key ) return true;
endforeach;
return false;
}
// Use it like:
if($post->hasMeta('author')){
// Display author
}
Read more about Laravels Eloquent relationships in the docs here: http://laravel.com/docs/eloquent-relationships
I once did something similar, my approach was to build a mini DB engine where forms are like tables and data is rows:
A form which describes the structure and design of a form:
Form {
id,
title,
layout,
...
}
Fields of the form with types and validation rules
Field {
formId,
name,
type (String, Date, Image, Integer, Double, List, ...),
pattern (Regex validation maybe),
...
}
Inserted data in a form is a row belonging to that form
Row {
id,
formId,
}
Each row is a group of entries to fields of the corresponding form that can be validated following the predefined rules.
Entry {
rowId,
fieldId,
value
}
Type and rules can be regrouped in another object so you can have dynamic types that you can manage.
Lists can have another object that stores choices and type of list (multi-select, mono-select)
Metadataobjects itself would be saved in one table. But performance-wise I think those object should their own data tables.
Approach 1)
These types of forms needs to be predefined and linked to a specific controller. This must be either so that there is only one controller for each type of form like Registeration, and only one user defined metadataobject can be in use at either time. This controller's table parameter would be set to point to a database table created specifically for that metadataobject (or perhaps same table could be migrated according to metadata but then that table should be empty).
Or 2) every metadataobject should have it's own controller created which points to the object's data table.
In each approach routes needs to be created to point to the one controller of each type at use in each time.
One dilemma is how to manage revisions of those objects. Perhaps each object might have a running number postfix, and have their own controllers and data tables created (then it might be easier to migrate even populated tables [then user would be notified on front-end if his action would result in data loss, like for example with deleting a form data field]).
Another part of this project is to create an intelligent generator engine for assembling the HTML, CSS, and JS code according to a metadataobject. The generated code can be saved to reside in the same table as the objects themselves, and when used should be cached in the backend for rendering views.
Such metadataobject must itself have a clever format, so that it composes of predefined pieces of settings which will be converted to functionality by the form generator code.
I'm using the cakephp framework to develop an application and I'm running into some trouble understanding the associations between these models fully. Below you can see the four models along with their relative database fields.
User
id
Profile
id
user_id
Post (A blog post on the users profile)
id
profile_id
topic_id
Topic (A topic for a blog post)
id
name
Here are the associations as they currently stand:
User
hasOne: Profile
Profile
hasMany: Posts
Post
belongsTo: Topic, Profile
Now my problem. I am unsure if you have to define associations like User hasMany Posts or if it's already assumed because User hasOne Profile and Profile hasMany Posts. My other problem is defining the relationship between a post and its topic.
A profile can have unlimited posts
A post must be associated with a profile
A post can only have one topic
The topic table contains a list of all topics
A post does not NEED a topic
Given these criteria how should my associations look? All the research I've done on associations only shows simple examples.
I'm using CakePHP version 2.1.3
Thanks for any and all help and/or advice in advance
You can recursively find associations of associations, or even better, use Containable.
In the model (I recommend putting it in AppModel, since I find myself using Containable for everything):
class AppModel extends Model {
public $actsAs = array('Containable');
...
}
Then when you call read (or find, or paginate) for User, most likely in your controller, do this:
$this->User->contain(array(
'Profile' => array(
'Post'
)
));
$data = $this->User->read();
$set('user',$data);
If you set that data to your view, you can then access the id of one of the posts from $user['Profile']['Post'][0]['id'].
Now for your next question, you can have conditional associations.
public $hasMany = array(
'Topic' => array(
'className' => 'Topic',
'conditions' => 'Post.topic_id IS NOT NULL'
)
)
I think everything looks fine
Your assumption is correct you dont have to define the User / Post relationship. Users dont have many Posts, Profiles do. You could store the user_id on the Post rather than profile_id to make thing a bit more intuitive but thats up to you.
Topic hasMany Post and you are done. The topic/post conditions you describe can be controlled via the forms and before saves on the model. For example 'A post must be associated with a profile', well at the point you save the post you add in the profile_id based on session info of the logged in user.