pony
pony copied to clipboard
ponyorm
Phantom object SitesStateFollowUp[6] appeared in collection SitesMonitor[52].siteStateFollowUp
I do not see any references to this kind of error doing google searches.
Can someone help me understand the meaning of this message.
The second DB SitesMonitor has a collection of SiteStateFollowUp records, so it is not unusual that a SitesStateFollowUp record would be found int SitesMonitor one to many collection.
What is the significance of the words "Phantom Object"
Not sure these guys are even working on this project any longer -- I use it but do not upgrade :)
On Thu, Sep 24, 2020 at 6:07 PM Andrés Herrera García < [email protected]> wrote:
Same here three years later.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ponyorm/pony/issues/259#issuecomment-698613797, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHAO5WCCARNEUDC56YTRVDSHO7KBANCNFSM4DI6JKNA .
Got snagged by this bug. The issue seems to come up when you have a db session open and you start another session in a different thread to create/delete a related object. For example, you have a web service that creates an item, then during the creation routine you invoke a different web service that creates another, related object in the database. When you come back from the second call, the relationship attribute may no longer be the same as what is cached, so this error gets thrown.
One workaround is to mark the relationships as 'volatile=True' in the database schema. This way, you're telling Pony not to assume the cache is valid and to re-fetch it each time it's referenced. It'll take a performance hit, but that works around the error.
Another option is to not call the second routine in a separate thread, but to have the item creation code in a library that is shared between both services. This way, item 1 is created, then you call the library routine to create item 2 in the same thread. This makes it faster, but you'll have to design the code to make sure the item creation/deletion routines all go through that one shared library.
Another thing to keep in mind is that LongStr values are marked as 'lazy' by default so if you try to reference them in that shared code library, they may not be available. Make sure to test that they're actually loaded, or mark them as 'lazy=False' in the schema definition to prevent lazy-loading.
From what I understand, this check is to prevent inconsistent results during one database session (if you read only, but do multiple queries) or prevent concurrent updates that overwrite each other accidentally (if you also write).
I know of three other possible solutions, besides the volatile option and using a single thread:
1. Make sure you request the same data only once during 1 session
If you can achieve this, you cannot get this problem, so that might be the easiest solution.
I found that it is easy to do several queries without realizing it. You can see this with the sql_debug option. If performance is important for you, this is probably the solution to go for, but it might mean you have to rewrite your code.
2. retry-option of db_session
See docs. While this was my preferred solution, I found that this tends to make the database inaccessible (SQLite, web server suddenly hangs after some time of normal operation, none of the database calls seem to get through anymore, as if it is overloaded). I also observed this with the "volatile" approach. I don't understand why, conflicts are rare and a single retry in that case shouldn't affect server load.
3. Disable optimistic checks of db_session
!! Only appropriate for read-only sessions, unless you rely on something else to prevent concurrent update problems !!
See docs. In my case, some extra records could pop up during the rendering of a summary on a web page, but for my application that's not important, so I choose to ignore the check.
I hope this helps! If people have similar experiences with "retry" and "volatile", I'd like to hear.
