temp view table left behind after delete

[azurewraith]

Hi there,

I ran into an issue experimenting with migrations and views in v0.13.1

I am using JS migrations to create collections and views, so that might play into the reproduction.

Steps:

• Create 2 collections in JS
• Create 1 view with an inner join involving those two collections in JS
• Delete the view (unsure if this happened in the Admin UI or not)
• Observe future migrations fail on a _temp_xxxx view table error (involving recreating the table that wasn't inner joined) SQL logic error: error in view _temp_j2yj1: no such table: main.table_name(1)
• manually enter SQLite and delete view _temp_j2yj1
• functionality returns to normal, migrations recreate that collection without failure

Hope this helps, I really dig the project!

[ganigeorgiev]

Could you provide a code sample? How do you delete the view?

[ganigeorgiev]

I'm not able to reproduce the issue but I'm also not sure that I understand the provided reproduction steps.

Please note that we currently don't keep track of what collections/tables currently takes part in a view query and it is possible that if you delete a collection (or some of its field(s)) that the view uses, it will thrown an error when trying to access the view. This is expected, although not documented very well at the moment. Users in this case have the option to update the related view collection query if they still want to keep it.

If you are still able to reproduce it, feel free to provide more details and I'll try to investigate it.

[azurewraith]

Thanks, I'm working on creating a file that reproduces this. In the described scenario, all three collections were deleted and the _temp view left was blocking the recreation of a collection. It could have been a fluke.

I've run into another interesting issue in the process, if I find anything reproducible by file I'll let you know

[ganigeorgiev]

@azurewraith Just to let you know that earlier another user reported similar issue related to the view collections import in #2044 and a fix was implemented in v0.13.3 release.

[azurewraith]

good to know, thanks! hopefully that was it but I'll keep an eye out. My testbed is better now and it starts everything out from a zero database state.