Okay, I've re-read your question and I think you have a few things wrong, so rather than leaving any further comments on the main post I figured I could have a go at an answer, so here goes.
First off, your relationship is the wrong type and the wrong way around. As I understand it (and as I implement these things in my own work) a product belongs to a brand - a brand may have multiple products, but a product can only have one brand. So first your DB schema - you mention you have a products
table with the normal columns and then the foreign key brand_id
. So far so good: this is consistent with the way I interpret the relationship.
However, you then go on to show us your model. You have the Product model as hasOne
Brand - but actually it belongs to a brand. You also don't define the inverse of the relationship - you need both sides to make Laravel work well. In addition to that your naming is a bit out of whack - it'll possibly work, but if we follow Laravel conventions we get the following:
In the products
model: Product.php
class Product extends Eloquent
{
public function brand()
{
return $this->belongsTo('Brand');
}
}
Now the brands
model: Brand.php
class Brand extends Eloquent
{
public function products()
{
return $this->hasMany('Product');
}
}
Okay so far so good. You'll notice various conventions:
- Table names are plural (
products
, brands
)
- Foreign keys use the singular (
brand_id
)
- Model names are singular and StudlyCase (so
Product
for a table products
, Brand
for table brands
)
- The
$table
property doesn't have to be specified as long as you follow Laravel conventions (i.e. table name is the plural snake_case version of the model classname
- You should define the relationship both ways (one in each model,
belongsTo
's inverse is hasMany
, there's also the pairs hasOne
/belongsTo
and belongsToMany
/belongsToMany
)
- The names of the methods to retrieve the relationship are sensible - if you expect one result, make it singular (
brand
in Product
), if you expect multiple results make it plural (products
in Brand
)
- Use the model classnames in your relationship definitions (
$this->hasMany('Brand')
not $this->hasMany('brands')
or any other variation
If you stick to these rules, your models can be really concise but very powerful.
Now, as for how you actually define real data, I have a feeling the code you posted may work fine (it really depends on how clever Laravel is behind the scenes), but as I suggested in my first comment, I'd ensure that I saved the $brand
before calling associate()
, just so that Laravel doesn't get lost working out what to do. As such I'd go for:
// create new brand and save it
$brand = new Brand;
$brand->name = "Brand 1";
$brand->save();
// create new product and save it
$product = new Product;
$product->name = "Product 1";
$product->description = "Description 1";
$product->brand()->associate($brand);
$product->save();
This way, you know you have the brand in the database with its IDs already defined before you go and use it in a relationship.
You can also define the relationship in the opposite manner, and it may be less brain-hurting to do so:
// create new product and save it
$product = new Product;
$product->name = "Product 1";
$product->description = "Description 1";
$product->save();
// create new brand and save it
$brand = new Brand;
$brand->name = "Brand 1";
$brand->save();
// now add the product to the brand's list of products it owns
$brand->products()->save($product);
You don't need to call save()
on either model after that last line, as it wil automatically take the $brand
's id
value, place it into the $product
's brand_id
field, and then save the $product
.
For more information see the docs on how to do this relationship inserting: http://laravel.com/docs/eloquent#one-to-many
Anyway, hopefully this post clears up a good amount of what was wrong with your code. As I said above, these are conventions, and you can go against them, but to do so you have to start putting extra code in, and it can be quite unreadable for other developers. I say if you pick a given framework, you may as well follow its conventions.
$product->associate();
Have a go at that. – alexrussellprotected $table = "brands";
line", but that's not true as far as I know. I'm pretty sure that model must have apublic function product() { return $this->belongsTo('Product'); }
method, that way the call toassociate()
on the $products model can fill in theproduct_id
field on theBrands
model. I'm not 100% with ahasOne
, but that's definitely how it is with ahasMany
, and it's the same kind of thing in the inverse of the relation (i.e. the model has aforeign_id
column). – alexrussell