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?

> every blocktype registered with a package
> has the db.xml associated with the block
> refreshed

Thanks, Scott!

-Steve

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?

Yep.

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

> 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

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.

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

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 :(.

If you're overriding the update method in your package controller, be sure to call at the beginning or end of the overridden method.