Bake not generating 100% new model-files?

My favourite cakephp-command is ‘cake bake all --everything -f’. My expectation was that using this command I got rid of all the changes I made to the code and should get a fresh build. But apparently at least some changes stay persistent.

For example, first thing I do after baking is changing display fields from id’s to another field. When rebaking, display-fields don’t change back to id’s. Console tells me models are rewritten (no errors), timestamp on file tells me it’s a new file.

Can’t find any info in the manual about this behaviour, is it a bug or is it a feature :slight_smile:

Sometimes I can’t get the baked application working properly after the ‘bake all --everything’, and I just delete all baked files. So I think I’m missing something?

What fields are you using as display fields? The bake often chooses other fields than the ids for me, like “name” or “description” strings, so maybe it’s just being smart enough to choose the fields that you wanted to use?

That’s interesting, I’ve bake never seen choosing another display field, always the ‘id’ (I’m using CakePHP 3.7). Maybe a convention I’m missing?

To test this behaviour, I use two tables, ‘compositions’ (with fields ‘id’, ‘composition’, ‘description’) and ‘items’ (with fields ‘id’, ‘item’, ‘composition_id’, ‘description’).

Bake generates innitially a model ‘CompositionsTable’ with DisplayField ‘id’. I repeatedly changed it to ‘composition’, ‘description’ and ‘id’ etc., after every bake the DisplayField kept the value I set it manually to.

The list of ‘items’ keeps showing the at that moment intended value for composition as set in the DisplayField.

Stumbling on the same question again. Now using cakephp 4.0.5.

Baked a working prototype based on a table with a lot of non-descriptive column names (like for example ‘_00023’). Using phpmyadmin I renamed some of them with a descriptive name (‘weight’).

Baking again (‘cake bake all --everything -f’) doesn’t seem to change for example model ‘mytableTable.php’. The validator still uses the old column-names (’-00023’). I expected bake to create new files with the new column names.

I’v seen no errors. I used all kinds of bake-commands like ‘cake bake model mytable --force’. Bake always asks to overwrite when not using --force, my editor always detects a new version of the file. So bake is writing a new file, but what’s is it really doing, and why is it not doing the things I expect it to do?

Deleting manually the src-directory, after bake the new files still use the old column names ??? There is some cache which is being used?

\tmp\cache\models, there is file which references to my table. Deleting this file, and bake works as expected.

How to configure the cache that when the table changes the file gets updated?

The awnser will be somewhere in

For the cache to automatically update whenever the table is changed would require that it check the table structure every time, which entirely defeats the purpose of caching. If you enable debug mode, it clears the cache much more frequently, and of course you can clear it yourself at any time. There’s even a bake command to clear it for you.

title and name are the default choices. I believe these choices do get baked in too.

In fact, here are the ‘bake’ callers of that method, so yeah, they bake in.

Will look into bake command to clear the cache, that should avoid the experienced problems.

Thanks. Did I miss this in the cookbook, or isn’t this feature described? Will read again.

I read it at some point in the past but couldn’t find it again in 4 docs. Didn’t look too hard though

Sorry, I mis-typed. It’s a bin/cake command, not a bake command.

Ah, after quick reading bake and cache pages in cookbook, didn’t have a clue yet :slight_smile:

Did have mixed results, sometimes I got the expected results, mostly not.

But it appears I was mixing things up. Baked specifiic model to change the display-field, sometimes followed by a ‘bake all’, and doing a cake cache clear_all now and then.

Step by step doing things and looking to the code after everystep etc. it’s obvious what happens.

The ‘cake bake model Table --display-field ColumnName’ sets the display field. When not doing anything else, the view-page stays untouched. Off course you have to do a ‘cake bake template Table’, then the view page shows the desired column name instead of the default ‘id’. My misconception was that the template used some kind of variable to show the display-field, so when altering the model, that would be enough. So, looks like this is now clear to me, nothing unexpected here anymore.

1 Like

So, now I’m back to the original post, with a little more knowledge, but still the same question.

When doing a ‘bake all --everything -f’ I expect bake to create a complete set of new MVC-files and templates based on the actual structure of the database.

When setting a different display-field instead of the default ‘id’, after the bake the display-field stays the non-default.

A cache could be the ‘problem’. Using the zuluru’s pointed to ‘cake cache clear_all’ before doing the bake, should solve it. But it doesn’t.

What’s the next thing I have to do to get the wanted behaviour? Otherwise, is it a bug or is it intended behaviour? When it’s intended, what more changes will be persistent (where to find?)?

What do you mean by “setting a different display-field instead of the default ‘id’”? Is this something that you do after running the bake? If so, then you would need to re-bake anything (most specifically, templates) that’s affected by that change in order for it to take effect.

id is not the default

I think it is sometimes, when it can’t find something it likes better?

Yes, as described in:

What I’m trying to do is to (re)build prototypes by using a batch file, so as a start:

  • cake bake all --everything -f
  • cake bake model Table --display-field column_a
  • cake bake template Table
  • etc.

In this way I hope I can concentrate on getting the database right when building a prototype. After making some changes to the database, and maybe some changes to the batch, I can get a prototype up and running on the fly.

In order to get this 100% working, that first bake has to build new files, so that’s where’s my concern.