Anyone has idea why Firebird update and delete foreign key rule, work in a inverse logical?
When you changes some data and it is a FK, the Firebird behavior :
First: delete master
After: delete details
When my guess that correct behavior would be:
First: delete details
After: delete master
This a big problem when you try to replicate the data to another database in runtime.
It is the delete on master that causes the cascading delete. On an implementation level this is handled by a system trigger on the table, therefor the delete on the master has to happen first, and the delete from details is the result of that.
I don't know how you are replicating the data, but you might want to check if you are using BEFORE or AFTER triggers to do this (however I don't know if changing BEFORE to AFTER would change firing order to detail-master).
For more detailed information on implementation and limitation, you might want to post a question on the firebird-devel mailinglist. There are people following that list who have also built replication software, and the core Firebird developers might provide more detailed info.
Related
I'm experiencing the following issue:
org.flywaydb.core.api.FlywayException: Validate failed: Detected applied migration not resolved locally: 1.44
That happened when I understood that the data that I added in 1.44 is invalid and I don't want to deal with it on old environments, but on new environments I don't want this data. I want the data that I will insert within new migration(e.g. 1.48).
If I change old migration it will fail on old envs due to checksum;
If I leave it, on new envs I will have invalid data from 1.44;
How can I delete it so that I accomplish what I need and not to get an error? What's the correct way?
This questions is related to Best pratice: How to modify flyway migration script after it has been used
The basic answer is: don't delete once it's been applied
It doesn't matter if during the migration process some intermediary state isn't exactly what you want, as long as the final one (1.48 in your case) is correct.
Now if you really need to delete this migration, ask yourself whether replacing it with an empty file could also do the job. If yes you could then follow the advice I gave here: https://stackoverflow.com/a/35491545/350428
Now if that's still not enough and you really really need to delete this migration, delete the file and patch up the flyway_schema_history table by hand to make it consistent again. This is risk-prone and should be an absolute last resort solution.
you can UNDO your migration: UNDO flyway migration
I have an audit mechanism for a project built with ef-core code first approach. I've set the "DeleteBehavior" property to cascade for some tables in "OnModelCreating" function. When I delete an entity, the other one deleted automaticly by cascade delete behavior. That's all good for now and I need to get all deleted entities, but I cannot. The ChangeTracker doesn't contain the cascade deleted entities. How can I get the cascade deleted values? Is there any way to do this?
Cascade Delete happen on the database side. Entity Framework doesn't need to be aware which entity will be deleted.
Entity Framework only tracks changes and delete the base object.
Edit: Answer subquestions
You are right. I'm the owner of EF+.
Technically, a library could handle this, but this will come with a severe performance drawback. I'm not aware of any feature or library which handle the cascade delete scenario for auditing.
Suggestion?
There is some suggestion, but I'm pretty sure you will not like any of them, and I don't either recommend them for performance reason:
Do not use cascade delete (force you also retrieving/deleting related entities)
Create ON DELETE Trigger and Log at database side.
I don't think a good solution exists for this scenario.
I am new to android and java and working on an app that has a few remaining problems that I haven't resolved yet.
I have a main activity that is a viewPager, with each page being a fragment. If the 4 fragments 3 are extended from ListFragments and one from PreferencesFragment.
The ListFragments have CursorAdapters to get data to and from SQLite databases through providers.
I am able to get data into the database, insert, modify and query the data correctly and fill the list views ok.
My preference setting are to choose different ways of viewing the data in the database.
Not knowing how to do this, I have implemented a process where I modify the cursorLoader query to the provider with a number of different choices of the "WHERE" clause. I have worked out the logic for the preferences as they exist now, implemented the code but had some difficulty finding what to try to trigger the refresh of the ListView.
Since the "dataset" hasn't really changed, no trigger can come from there, plus that would just use the same cursor as it currently exists to run the query again and return the same results (or be smart enough to know that it doesn't need to run).
On Stack Overflow I did find a couple of references to a similar implementation that suggested reStarting the cursor loader, which would then on the reStart read the current values in the stored Preferences file, create a now modified WHERE clause that will show the sub-set of data as specified in the preference settings.
In testing the app now, even with the reStart of the cursorLoader, the ListView isn't getting refreshed.
The only time I can get it to work right is restarting the app. If I stop the app and restart it, the new values are used and the ListView presents as the preferences dictate.
In looking through Stack Overflow and the Android site, I did find another set of APIs that might have been a more natural fit for what I am trying to do, namely the Filter APIs.
First question then would be, did I go in the wrong direction on how to control the "filtered" view of the datbase. Is filtering a better approach and a recommended way of
doing what I am trying to do?
Second question would be related to the fragment lifecycle of my ListFragments to achieve this CursorLoader update.
Thanks for any input on the topic.
-Dan
Found my problem here.
Two things, the way I am trying filtering is working and from what I have seen in the
Android development site, a reference there indicated that the filtering capability is
already implemented in the CursorAdapter, CursorLoader classes I am using.
When my preference settings changed, I did a reStart of the cursorLoader, but had restarted the wrong one.
Problem solved. Any input on is there a better way would be appreciated.
Regards, Dan
What are the practical advantages of Doctrine Migrations over just running a schema update?
Safety?
The orm:schema-tool:update command (doctrine:schema:update in Symfony) warns
This operation should not be executed in a production environment.
but why is this? Sure, it can delete data but so can a migration.
Flexibility?
I thought I could tailor my migrations to add stuff like column defaults but this often doesn't work as Doctrine will notice the discrepancy between the schema and the code on the next diff and stomp over your changes.
When you are using the schema-tool, no history of database modification is kept, and in a production/staging environment this is a big downside.
Let's assume you have a complicated database structure in a live project. And in the next changeset you have to alter the database somehow. For example, your users' contact phones need to be stored in a different format, not a VARCHAR, but three SMALLINT columns for country code, area code and the phone number.
Well, that's not so hard to figure out a query that would fetch the current data, separate it into three values and insert them back. That's when migrations come into play: you can create your new fields, then do the transforms and finally drop the field that was holding the data before.
And even more! You can even describe the backwards process (the down migration), when you need to undo the changes introduced in your migration. Let's assume that someone somewhere relied heavily on the format of the VARCHAR field, and now that you've changed the structure, his piece of code is not working as expected. So, you run migration:down, and everything gets reverted. In this specific case you'd just bring back the old VARCHAR column and concatenate the values back, and then drop the fields.
Doctrine's migration tool basically does most of the work for you. When you diff your schema, it generates all the necessary up's and down's, so only thing you'll have to do is handle the data that could be damaged when the migration is applied.
Also, migrations are something that gives other developers on your team knowledge on when it's time to update their schemas. With just the schema-tool, your teammates would have to run doctrine:schema:update each and every time they pull, `cause they wouldn't know if the schema has really changed.
When using migrations, you always see that there are some updates in the migrations folder, which means you need to update your schema.
I think that you indeed nailed it on Safety. With Migrations you can go back to another state of the table (just like you can do in Git version control). With the schema update command you can only UPDATE the tables. There is no log kept for going back in case of a failure with already saved data in those tables. I don't know exactly, but doesn't a migration also saves the data of the corresponding table that's being updated? That would be essential in my opinion, otherwise there is no big reason to use them.
So yes, I personally think that the main reason for using migrations in a production environment is safety and maybe a bit of flexibility. Safety would be the winner here I think :)
Hope this helps.
edit: Here is another answer with references to the Symfony docs: Is it safe to use doctrine2 migrations in production environment with symfony2 and php
You also cant perform large updates with plain doctrine migration. Like try to update index on 30 mln users database. As it will a lot of time while you app will not be accessible.
In our application,Many pages includes "update" and when we update a table,we update unnecessary columns,which dont change,too.
i want to know that is there a way to avoid unnecessary column updates?We use stored procedures in .net 2003.In Following link,i found a solution but it is not for stored procedures.
http://blogs.msdn.com/alexj/archive/2009/04/25/tip-15-how-to-avoid-loading-unnecessary-properties.aspx
Thanks
You can really only accomplish this with a good ORM tool that generates the update query for you. It will typically look at what changed and generate the query for only the columns that changed.
If you're using a stored procedure then all of the column values get sent over to the database anyway when you call the stored procedure so you can't save there. The SP will probably just execute a run-of-the-mill UPDATE statement. The RDMS then takes over. It won't physically change the data on disc if it's not different. It's smart enough for that.
So my answer in short: don't worry about it. It's not really a big deal and requires drastic changes to get what you want and you wont even see performance benefits.
When I was working at a financial software company, performance was vital. Some tables had hundreds of columns, and the update statements were costly. We created our own ORM layer (in java) which included an object cache. When we generated the update statement, we compared the current values of every field to the values as they were on load and only updated the changed fields.
Our db was SQLServer. I do not remember the performance improvement, but it was substantial and worth the investment. We also did bulk inserts and updates where possible.
I believe that Hibernate and the other big ORMs all do this sort of thing for you, if you do not want to write one yourself.