search

Deadwood-ai / deadwood-api

Main FastAPI application for the deadwood backend
GNU General Public License v3.0
0 stars 0 forks source link

project_id cannot be int #37

Open cmosig opened 3 weeks ago

cmosig commented 3 weeks ago

I changed it to str in this repo, but supabase does not let me change it from int to string, because another table has a view on it. @mmaelicke can you do that? Not sure about the structure of the supabase tables.

mmaelicke commented 3 weeks ago

It cannot be changed to text because it's an identity column. That has to use an integer. Is there any reason why the id should be str? Then I drop and recreate it with string.

cmosig commented 3 weeks ago

Yes, because the project_id is a string in the metadata... it is also like that in the sample metadata.csv that I sent a couple of months ago. Not sure how it ever worked on your end with an int :)

mmaelicke commented 3 weeks ago

Well, the projects were added by hand. Usually you would use a numeric primary key and then something like a short_title and a title (and maybe desription). I would really discourage using text primary keys. They slow everything down and cause problems on cascading changes.

However, I forced supabase to create the column and would refactor that later. With this structure, we will not be able to change project names properly (without screwing everything up).

Please also make sure, that you change the local API to accept string project ids. I am not sure if that works.

The plan at the time was to model that properly. With using just a 1:n cardinality between metadata and projects, every image can only ever be part of a single project. My last info was that it might be desirable in the future to define more than one project that an image can be part of. If that is not needed anymore, I can also just refactor the data types after the upload is completed.

Pls be aware that I am already on vacation and will not be able to respond to issues regularly anymore...

cmosig commented 3 weeks ago

It works now, thank you.

cmosig commented 3 weeks ago

And yes, we 1:n for orthophoto-metadata to project is fine and is the case. Refactor after upload however it is best.

Regarding the plan to expose project groupings to the user we should wait until everyone is back from vacation and make a decision together. This is low-prio feature imo.

Until when are you on vacation?

mmaelicke commented 3 weeks ago

approx. 16.9.

Yeah sure. Whenever suits you. The exposure of project information on the website is independent of the refactoring for the database.