Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Set permissions and/or add database triggers?

    Or maybe I still don't quite get the problem...

    • Let me elaborate... Suppose you develop some application that uses a database as a backend. You store pretty much everything in your database, including user-modifiable data (the stuff you expect your user to change because that's the purpose of the application) but also the data that's important to the application itself. Let's assume you have some help files stored in the database. There is some chance that the user translated them, did some extra HTML cleaning, etc. For the upgrade, we shouldn't really overwrite the user-data but we would like to overwrite the application data. Adding a checksum seemed like a good idea because that way we can be sure something has changed and we can ask the user for confirmation. Also consider that the user has current data already in the database.. using the normal schemas. Adding extra triggers is not really going to help in upgrading now (it might for the next upgrade ofcourse, ignoring the fact that those triggers are often RDBMS specific or even version specific and that we run this app on a multi-RDBMS platform).

      Does that make any sense?
      • Oh, I get it now. I've seen one app deal with it by keeping the user-defined data (help messages and prompts and things like that) separate from the default system data. If the user updated anything, it was copied and then flagged as user defined. The app preferred to fetch the user defined data first, then the non-user defined data. That way you could update the default app data without overwriting the user defined data.