Why Does Laravel Ignore My DB Structure Changes and How to Stop it,

1. Migrations are just to setup the structure of your database tables. You don't "need" them but it can be handy when you need to undo a change you made (or maybe you don't know what you did and you can't find any logs of it).

2. You can just build your database and use Eloquent like normal, just don't try and use php artisan migrate commands :)

3. Migrations are good, should really give them a shot

Extra: You can add, rename and change varchar amounts by using a single migration file (not editing the original). But of course that would only be needed if you haven't made your app live and you don't want to run php artisan migrate:rollback

http://laravel.com/docs/4.2/migrations

Yes, if you run the commands again it will overwrite any manual changes you did to the database.

1. Absolutely NOT. They aren't even related other than both touching the database.

2. Yes. Are you caching your database queries? It sounds like it. That doesn't normally happen.

3. There are some niceties you would lose like mutators, relationships, soft deletes, automatic transformations of your timestamps to Carbon/DateTime object, etc.

3 was a misread on my part :P

You don't need to use migrations at all, but if you do then you need to stick with it - or go so far and then never use it again if you decide to manually alter your db.

You can easily rename a column in a migration though. Say for example you need to change the column name from "location" to "address" in the "users" table:

Schema::table('users', function($table)
{
    $table->renameColumn('location', 'address');
});

Thanks for all your replies.

I don't mind migrations in principal, but writing out all that stuff: $table->renameColumn('location, address'); etc etc etc when I can just go to PHPMyAdmin and in 2 clicks I have it done.

I guess my real question, and which I should have been more articulate is, if migrations are optional, then why does Eloquent not respect the table structure I have.

For example, If I make a manual change to a column name, change "id" to "product_id" through Phpmyadmin, then why is it that I get an Eloquent error message saying that it can not find the column, indeed saying that the column should be called "id".

Of course Eloquent obscures the sql, but if migrations are optional, then how does Eloquent know what the column should be called, and why does it get it wrong, going for what it was when initially migrated ?

As always Many Thanks !

I'm no Jeffrey Way, but I think the ORM is based on the model defined, and I suspect it looks for an ID field by default - if you're using a differently named field, you may need to specify it in the model. If you look at your laravel/framework/src/Illuminate/Database/Eloquent folder you'll see a model.php file in there, and around line 46 it says $primaryKey = 'id';

Thats in the model class, so anywhere you're using that, I'd suspect you'd want to override the default with the name of your field.

I suspect if you'd started with a differently named primary key, you'd have had this issue, even if you used the migration mechanism.

Many of your questions will be answered from the documentation: http://laravel.com/docs/4.2/eloquent

For example, If I make a manual change to a column name, change "id" to "product_id" through Phpmyadmin, then why is it that I get an Eloquent error message saying that it can not find the column, indeed saying that the column should be called "id".

This particular case has less to do with migrations and more to do with how Eloquent finds records. When you do something like

$user = User::find(1);

you are really doing an implied sql query that looks like this:

SELECT * FROM users WHERE users.id = 1;

When you change the primary key of a table, you have to let Eloquent know what the primary key is by setting a property on the model called $primaryKey.

You can find more information here: http://laravel.com/docs/4.2/eloquent#basic-usage

1. No
2. Yes
3. No problem. You can easily mix the use of both as well as I indicated in my reply to your post about converting SQL to laravel n:n

Apart from anything else, the value of migrations is simply that when you move your system to another server (say production), you can just run the migration and your database is set up correctly for you. Ditto with seeds.

Sure, you can export a schema with phpMyAdmin, then import it somewhere else, but that's not scriptable whereas artisan xxx comands are. Via migrations your schema is versioned together with the associated codebase when using github etc.. Your schema is coded incrementally allowing you to granularly make changes and spot errors. It's self documenting. It will handle the underlying database changing transparently with datatypes set through sensible wrapper types; want to move from SQLite to MySQL? Easy. There are numerous advantages. Having said all that, you're not required to use them.

So far as eloquent is concerned, there's no inter-dependency. Eloquent will always work with the database as-is. Eloquent makes certain default assumptions (like id for primary key) which can be easily overridden, just like the majority of laravel defaults. As mentioned above, it might be worth a read through the docs.

It's important to understand that eloquent is not some magical alternative to SQL. More importantly, it's not 'better'. The eloquent ORM expressively fits some design problems very well and others less so. With laravel you are free to use or discard eloquent, mix eloquent with fluent syntax (wrapping SQL in laravel's syntax) or just use plain SQL with DB::select, DB::insert or even DB::statement. Rather than using relations and eager loading, for example, you can just build a query with joins straight off your eloquent model. Depending on what you're trying to do, either approach can be more efficient and appropriate, and sometimes a mix of both is ideal.

Many thanks - I really appreciate the work you put into your reply. Coming from a CodeIgniter / raw PHP world, a lot of this stuff is quite new. I am glad that is it not obligatory to use.

For me, as I am not working in a team, speed of development is paramount.

Never the less, I am learning Laravel for a purpose. That being to build code whilst adopting best practices.

If I can perhaps use Jeffrey's Generator service, perhaps I can speed up migrations a bit. I will follow your advice and not entirely give up on Eloquent, but rather use it where useful, and resort to Query Builder otherwise.

Many thanks !

Last thought: At this point in time, Eloquent seems most suitable when there is a simple one to one, one to many relationship, where as complex multi-table joins could be better suited to QB.

I think you might agree ?

In complex situations I usually end up with a mix, often using query scopes to modularise and optimise. The balance will depend on what I want to do with the data. It helps to gain an understanding of how eloquent's approach to relations and eager loading differs from SQL joins. It can help to make a route and dump out the result of an your eager-loaded eloquent relations with, for example

Response::json(User::with('posts')->get());

Also this page helps explain the basics of relations and eager loading quite nicely.

@vincej I'm a bit surprised by the fact that you don't see the use in migrations, but on the other hand I had to get used to them as well when I started with Laravel.

You are speaking about working in teams, and that that is when you need migrations. Yes that can help you when working in teams, but it is also very useful when you are (like the most users at this site I imagine) a sole developer.

Why use migrations you might think. In my opinion it is part of your workflow. On your local computer or a virtual Homestead environment you develop your application. Once you think it is production ready you deploy it to lets say a DigitalOcean server. But as is often the case you realize that (lets take an example) you also want to give the user the ability to add the user phone number to his profile. Without migrations you will need to add this column to your users table manually on your development environment, write all the associated code, deploy to the production server and you will have to update the table on your production server manually.

When using migrations you will only have to add it to a new migration file (named datestring_update_users_table.php) and run the migration on your local development environment and on your production environment.

But what it the most important function for me is that during development it gives you the possibility to rollback your changes. Combined with table seeders for test data this makes adding new tables/columns etc. a whole lot easier.

An other reason to use migrations, you will have an overview of your table structure in a very readable manner in your project. If you forgot how you named a table or column you just have to take a look at the migration and you don't have to go to phpmyadmin every single time :)

Give it a try for a couple of weeks and remember that you use the generators package created by Jeffrey and that for every change you make to a table you create a new file or you rollback the previous migrations and update existing ones (but remember that you can't do that on your production environment since it will remove the data associated with that migration).

Just my view on it :)

@vincej Did you not use Datamapper with CodeIgniter? Working with it now in fact :P it's so bad compared to Laravel ORMs...

http://datamapper.wanwizard.eu

I very much appreciate everyone's lengthy contributions. Thank you.

This is as much about me as it is about the technology. Moving into Laravel from a world of raw code + CodeIgniter is like moving from a tricycle to a Lear jet. I don't want to be a hack. I want to do things properly. Thing is I don't know what the Laravel "best practices" are yet.

I am revealed to see that I am not obligated to use migrations nor Eloquent. Never the less, I will make an extra effort to appreciate their use and their value. I am torn. I can bang out raw SQL as fast as Jeffrey can deliver Eloquent statements. I can build a Database in minutes. When I spend hours researching an Eloquent strategy or fighting with migrations, which I can deliver in SQL in a minute, well it makes you doubt what you are doing.

Still, everything worthwhile is tough at the beginning ...

Many thanks again !

Cheers Vince !

@vincej The datastructure is very important. Keep it as simple as possible. If you need to do complex multitable join queries that's a problem with the datastructure, not with eloquent.