-
Notifications
You must be signed in to change notification settings - Fork 409
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fit projection relationship not deleted properly #90
Comments
Issue fixed as of 2651a04 The first fix didn't work out. To remove the projected fit from the loaded Fits, the easiest way is to simply I simply reverted the original commit and did it differently. Now when you remove a fit, it queries for fits links to it in the Projected table, then iterates through them removing the projected fit. It finally then removes the fit. I had to tweak a few other things to get the active fit to refresh correctly. |
Bugfix: Appveyor build numbers
I already have a fix for this (kinda, see blitzmann@a2727d5), but in the interest of documentation I am creating this issue.
While looking into the various bugs pertaining to projected fits (many of which have been since fixed), I discovered that the relationship in the database is not properly deleted. This causes some issues (including silent crashing requiring restart) as SQL Alchemy can reuse auto-increment IDs. Collisions can occur.
For example, if you have
B -> A
, and deleteA
, the relationship is deleted correctly. However, if you deleteB
, the relationship sticks around. If you deleteB
and then create a new fit (C
, which can take the ID ofB
and reuse it for itself), and then try to projectC -> A
, Pyfa crashes because it tries to add the exact same information into the database which is already there (since the oldB -> A
wasn't deleted).This happens because when you delete
A
, sqlalchemy cascades that deletion to the relationship (which only pulls fits projected ontoA
). However, if you deleteB
, theFit
object doesn't have any relationship data to delete.The quick fix is to simply query fits that are projected onto the current fit and fits that the current fit is projected onto. This way, when deleted, we know that all relationships are properly removed.
Now, for the "kinda fixed" part. When you delete a projected fit, that change is not reflected in currently loaded fits. So the UI can still show that there is a fit projected when it has been deleted. This can cause a crash if you try to copy the fit (as it tried to copy the projected fit which no longer exists). Not sure how to fix this just yet.
The text was updated successfully, but these errors were encountered: