Whenever I run propel-gen on a clean database (no tables defined), it generates errors because it first tries to DROP a table (Which doesnt currently exist) before creating it.
Is there any properties I can change to fix this?
So far I've found this:
http://www.propelorm.org/ticket/732
But it would be nice to do something like "DROP TABLE IF EXISTS name"
I faced the same problem some months ago but couldn't find more than the trac ticket (you will find, as well, that I have commented it :-)).
Maybe try to apply Elan Ruusamäe's patch if you find this bug very annoying...
If I have enough time/motivation, I may write a patch too (to make Propel issue a CREATE TABLE IF NOT EXISTS for DBMS supporting it) and hopefully the fix will be scheduled for one of the next versions.
Related
I have created database project in visual studio 2013 from existing database. Then I have done lot of changes in database project like modify stored procedures, post deployment script, table structure, etc . Now database project is ready to deploy. But I am worry if any script fails then How I can retain the original state though it build properly.
Please suggest that if any query fails then I want ROLLBACK the all changes that I have made in database project.
Firstly you need to trust your tools and either believe they will work or find other tools.
While you are building the trust I would add a create backup to the pre-deployment script or run a backup before you deploy then if anything goes wrong you can restore and figure out what went wrong.
As David said to roll-back, you would get the previously deployed dacpac and generate a new deployment script from that but fixing forward is almost always the correct thing to do rather than rolling back to a previous version.
ed
Have you been checking your changes into version control? If so, all you need to do is to revert back to the last known good version.
Or... simply work out why it's failing now and fix the root cause?
I used Db projects some time ago and as far as I remember the deploy script was wrapped in a transaction. It is possible to generate sql script without executing it. That setting was somewhere in DB project settings. You can take a look inside that script and make sure that it'll rollback on error.
Doing a backup would still be a recommended practice especially when you deploy to production.
when working on important scripts I developed a habit of always starting a transaction and commenting out the commit.
If you accidentally run it, it won't take effect. The commented out commit would only come out when the thing was done.
While this answer indicates that you CAN revert in source control (Assuming SSDT at this point) it would be nice to get a pointer to the exact process to do this. On a file by file basis the history works the same but how to revert the entire database at once isn't immediately obvious.
I'm a little stuck in a postinst file for Ubuntu.
The problem is when upgrading the package. I have some sqlite databases (marked as config files to save them from upgrades) in which I want to modify in a specific version (add some columns). As only I want to modify the database when installing an specific version (for example from version 3 or older to 4) I check if $2 is not null.
The approach to make the database upgrading is as follows:
first I make a backup of the databases
make new table
Then I alter the tables
copy the rows from the old table to the new one
The problem is if something goes wrong, the database already will be modified but the package will be at the new version (the four) with config version at 3. If I want to try install again the package in order to get the package ok, the postinst will fail because the database was already modified.
One thing that came to my mind was unset -e, but I find this very unpleasant.
I've searched in the documentation about how to revert fails from postinst, such as if it's called another script with different arguments, but in the documentation Debian says nothing useful.
Maybe the postinst script is not the best place to modify databases?
Thanks
Best regards
One thing you could do is check if the field already exists on the table, and alter in that case.
That is not dependent on if this is an upgrade or not.
Like this for example:
if sqlite3 /collection.db '.schema media' | grep -q 'new_field text' ; then
echo field already exists, continuing
else
sqlite3 /collection.db 'alter table media add column new_field text'
fi
Also, I would recommend the database schema to be manipulated by the application, and not dpkg.
Imagine that the user might restore a backup from an older version and "break" your software.
It should be clear to the user that the database of older versions is incompatible with the newer version.
I would recommend you to search the internet for help in creating a "migration plan".
Basically that means that you keep track of what "version" the database is and apply sequentially the database modifications when needed, in a way that is very similar to how a patch works.
The scenario that created this question:
We have a package that is a dependency of another package, sometimes making changes to the "parent" package causes the dependent package to become invalid, but sometimes it doesn't.
It has caught us by surprise before.
It would be very useful to simply understand what causes invalidation so I could predict/plan for it.
Changing anything object that a package relies upon (e.g. tables, views, triggers, other packages) will automatically mark the package as invalid. As tuinstoel notes above, Oracle is smart enough to recompile the package when it is first used.
If you are concerned about this, every time you make schema changes (e.g. tables, views, triggers, procedures), run a DBMS_UTILITY.compile_schema (or have your DBA do it). This will force compile all the packages and let you know where, or if, there are errors before you find them the hard way.
Or you can query the following table to see what dependencies you have
select *
from dba_dependencies
where name = 'YOUR_PACKAGE'
and referenced_owner = 'ANYUSER' --- Comment this out if you are looking for yourself
and owner = USER --- Or can be set to any user
This will show all dependencies. For your objects query user_dependencies.
I agree with Thomas Jones-Low however there are a couple more issues to do with long sessions and recompilation.
If you reference a package in a session and that package (or a dependant package) gets recompiled during the same session then you'll get oracle error "ORA-06508: PL/SQL: could not find program unit being called"
Once you've referenced the package in a session you generally can't change the package without invalidating it for that session. This is a particular problem for development environments where packages change frequently but also a problem for production environments where you want to do a small patch without taking the whole environment down. Note that this error will occur even when there are no errors in the changed packages.
BTW, If I'm completely wrong about the situation... apologies in advance
Caught by surprise?
Not sure what the implications of that are...
Did something break in production?
What EXACTLY happened?
The reason I ask is because understanding every possible change's ramifications is much harder than dealing with the outcome. Why the invalidation become an issue? My guess is because you got an "Existing state of Package has been discarded" error in your application. Is that the REAL issue?
Again I suspect that it is and if so, let's just deal with that instead of the list of changes which as I put in a comment is version specific. (11g tracks dependency down to the column of a table instead of the table as a whole for example).
This may not seem like an important error to you if you're not using package state. If you were this would be an important error and you wouldn't have been surprised, so I'm guessing you're not.
Since you are not this error is ok to ignore. Since you can safely ignore it, you can code your client app to ignore this error and retry your call, because, as others have pointed out Oracle will recompile your package for you. This is a worthwhile exercise. Because rather than knowing every possible thing you need to worry about when you make a change, and then in the emergency fix you forget one of those, your app will just handle it and move on, without worry.
In addition to Thomas Jones-Low's answer, if you only modify the package BODY, a dependent object might not be marked as invalid.
However, as soon as you modify the package specification, that is bound to happen.
If try to execute an invalid Oracle package, Oracle will try to compile it. Only when it remains invalid after compiling Oracle will throw an exception.
I have developed a Joomla extension and in the newest version the need to delete one column from a table belonging to my plugin has arisen.
As far as I know there is no easy way to delete a column in Mysql only if it exists. Therefore, the only possibility I see at the moment to achieve that, would be to use custom php upgrade code, as shown here.
But this problem would seem so common to me, that I would suspect to be an easier solution?
Is there maybe an easy way (provided through Joomla) to execute a schema change only when updating from a particular extension version?
Check Managing Component Updates with Joomla; starting with Joomla 1.6 there is a defined way to execute specific SQL instructions for an upgrade from one version to another. Basically, for each version an SQL file has to be created (even if it's empty or only contains comments) in a specific file structure. The linked article explains the details.
The scenario that created this question:
We have a package that is a dependency of another package, sometimes making changes to the "parent" package causes the dependent package to become invalid, but sometimes it doesn't.
It has caught us by surprise before.
It would be very useful to simply understand what causes invalidation so I could predict/plan for it.
Changing anything object that a package relies upon (e.g. tables, views, triggers, other packages) will automatically mark the package as invalid. As tuinstoel notes above, Oracle is smart enough to recompile the package when it is first used.
If you are concerned about this, every time you make schema changes (e.g. tables, views, triggers, procedures), run a DBMS_UTILITY.compile_schema (or have your DBA do it). This will force compile all the packages and let you know where, or if, there are errors before you find them the hard way.
Or you can query the following table to see what dependencies you have
select *
from dba_dependencies
where name = 'YOUR_PACKAGE'
and referenced_owner = 'ANYUSER' --- Comment this out if you are looking for yourself
and owner = USER --- Or can be set to any user
This will show all dependencies. For your objects query user_dependencies.
I agree with Thomas Jones-Low however there are a couple more issues to do with long sessions and recompilation.
If you reference a package in a session and that package (or a dependant package) gets recompiled during the same session then you'll get oracle error "ORA-06508: PL/SQL: could not find program unit being called"
Once you've referenced the package in a session you generally can't change the package without invalidating it for that session. This is a particular problem for development environments where packages change frequently but also a problem for production environments where you want to do a small patch without taking the whole environment down. Note that this error will occur even when there are no errors in the changed packages.
BTW, If I'm completely wrong about the situation... apologies in advance
Caught by surprise?
Not sure what the implications of that are...
Did something break in production?
What EXACTLY happened?
The reason I ask is because understanding every possible change's ramifications is much harder than dealing with the outcome. Why the invalidation become an issue? My guess is because you got an "Existing state of Package has been discarded" error in your application. Is that the REAL issue?
Again I suspect that it is and if so, let's just deal with that instead of the list of changes which as I put in a comment is version specific. (11g tracks dependency down to the column of a table instead of the table as a whole for example).
This may not seem like an important error to you if you're not using package state. If you were this would be an important error and you wouldn't have been surprised, so I'm guessing you're not.
Since you are not this error is ok to ignore. Since you can safely ignore it, you can code your client app to ignore this error and retry your call, because, as others have pointed out Oracle will recompile your package for you. This is a worthwhile exercise. Because rather than knowing every possible thing you need to worry about when you make a change, and then in the emergency fix you forget one of those, your app will just handle it and move on, without worry.
In addition to Thomas Jones-Low's answer, if you only modify the package BODY, a dependent object might not be marked as invalid.
However, as soon as you modify the package specification, that is bound to happen.
If try to execute an invalid Oracle package, Oracle will try to compile it. Only when it remains invalid after compiling Oracle will throw an exception.