Alternatively, you can just skip the insert task, and selectively grab
tables from the generated sql definitions in /data/sql/..
Paste those into mysql, and you got a new table as well. As for
modifying existing tables, that would truly fall under migration,
and unfortunately it involves some
Can you explain this in detail? Why would modification of existing tables
require migrations?
Theoretically, I would just use build-schema, to imitate the changes that I
make to the existing db tables. Follow it up build-model, to regenerate the
model files. If that is a problem, I could delete
Because just building your schema does not change your database at all. If you
changed a column type from string to int then you'll have to manually change
that column type in the database. Migrations are a way to do that automatically
(kind of).
Daniel
On 28.04.2010, at 09:58, Parijat Kalia
Okay, that I understand. My only gripe with this would be that the file it
generates is so long as it does not use the consise (or compact) form. Kind of
hard to browse a schema that has all models in it and needs 100 lines for
each, even when it only contains a few columns. Mhm.
Other than
On Wed, 28 Apr 2010, Parijat Kalia wrote:
you missed out part of the conversation. The Idea is to change the database
manually yourself. Then use build-schema to get the schema file up to date.
This you do so that when you run build-model, it reads an up to date schema
file.
As I said
