Incorporate DB Changes Into Packaged Block Update?

Permalink 1 user found helpful
I can't seem to locate any clear concise information about how to update a package (or more specifically,a block within a package) with database changes. For example, let's say the new version of my block requires a new database field. How do I add that field using the package update process so that it happens automatically when users update their package?

-Steve

Shotster
View Replies:
ScottC replied on at Permalink Reply
ScottC
your block's db.xml field in the block(type) must contain the changes, if you dig into the package update mechanism you'll find that every blocktype registered with a package has the db.xml associated with the block refreshed, along with the db.xml which is optional and if present in the root of your package directory.

So depending on the package and if the scope of the schema'd tables you'd want to make changes in either place, but since you are talking about blocks you'd want to make the changes in the blocktype's db.xml defined schema xml.

That make sense?
Shotster replied on at Permalink Reply
Shotster
> every blocktype registered with a package
> has the db.xml associated with the block
> refreshed

Thanks, Scott!

-Steve
SkyBlueSofa replied on at Permalink Reply
SkyBlueSofa
I've been wondering about this myself.

Are you saying that if I update the db.xml file associated with a package block and add new columns, then run an update on the package (new version) that it will automatically create the new columns in the database?
Shotster replied on at Permalink Reply
Shotster
Yep.
ScottC replied on at Permalink Reply
ScottC
yes though I have had it fail a few times, so i just dropped the tables then ran update. You kinda want to iron out that stuff before you release a package :)

-scott
Shotster replied on at Permalink Reply
Shotster
> yes though I have had it fail a few times,
> so i just dropped the tables then ran update.

Now I'm a bit confused, Scott. Are you saying the update mechanism failed during development/testing or that it has failed in the field? I mean, dropping tables would result in data loss, so I'm assuming it's not a strategy you incorporated into the released package.

Any idea why the update failed?

-Steve
ScottC replied on at Permalink Reply
ScottC
nah, if you change the db.xml and you trigger a package update(incrementing the package version slightly is the easiest way) then your db.xml schema will be reflected in the tables defined in the schema.

If for some reason you have problems with the schema changes not being reflected, still leave it in the db.xml, but change the table definition manually. This is pretty damn rare but it has happened to me, but not often enough to try to figure out why there was a problem.
Shotster replied on at Permalink Reply
Shotster
Thanks for the clarification, Scott. I guess that what confused me was the phrase "dropped the tables" which seems to imply that the data go bye-bye.

-Steve
mkantor replied on at Permalink Reply
mkantor
I've had things fail when I change the constraints for an existing column (default value, NOT NULL, etc). It seems like C5 doesn't notice these kinds of changes and keeps the column definition as-is. I haven't had a chance to dig deeper on the issue yet, though.

The worst part is that depending on the nature of the schema changes and what your package does during install this can be a silent failure and only come back to bite you once you have a bunch of invalid/inconsistent data already stored :(.
dzimney replied on at Permalink Reply
dzimney
If you're overriding the update method in your package controller, be sure to call
parent::upgrade();
at the beginning or end of the overridden method.