Remove static models

[yannik131]

Closes #1048

[yannik131]

Migration guide for me

Turning eloquent model X into enum X requires these changes:

Enum implementation

Assuming all possible model values are written into the corresponding X table upon migration

• Find values by connecting to the db (docker compose exec database psql -U biigle -d biigle -c "select * from X;") and by looking at DB::table('X')->insert statements, insertion order corresponds to values, 1-indexed
• Assign integer values to each existing case using the same values and implement
• cId() returning the value of case c for each case
• c() returning the case cfor each case
• label() returning the case name like it was previously written in the DB
• toArray() returning ['id' => xId(), 'name' => label()]

Creating the migration

Find all foreign keys and their constraint names using docker compose exec database psql -U biigle -d biigle -c "\d+ X", then

• (make sure enum and database table are 1:1 congruent on present IDs/values as a failsafe: MAYBE if migrations don't fill the tables completely?)
• drop all fk constraints
• drop the table itself

Editing old migrations

Instead of removing the tables from the migrations, it's easier to keep them and replace eloquent model method calls X::method() (all(), insert(), ...) with DB::table('X')->method().

Common needed replacements

X is the name of the model and enum, x is lowercase name, x_id is (usually) the name of the FK

• X::all() -> collect(X::cases())->map->toArray() (add ->values() if PHPStan is pedantic)
• $val = X::findOrFail($caseId) -> $val = X::tryFrom((int) $caseId); abort_if($val === null, 404);
• similarly, other model-specific query patterns X::find(), whereHas(), with(), whereRelation()
• collect([X::case1(), X::case2(), ..])-> collect(...)->map->toArray()
• FormRequest validation rules like 'x_id' => 'integer|exists:x,id' -> 'x_id' => ['integer', Rule::in(array_column(X::cases(), 'value'))]
• $this->belongsTo(X::class) -> X::from($this->x_id)
• Eloquent model has x() method -> getXAttribute(): X. This way $object->x still works
• blade files: {!! Biigle\X::x() !!} -> @json(Biigle\X::x()->toArray())
• $x->id -> $x->value
• $x->name -> $x->label()
• $object->x()->associate(Biigle\X::case()) -> $object->x_id = X::caseId()
• remove DB-specific X-tests
• XTest::create() -> X::case() (find out default case or just choose one)
• X::pluck('id', 'name') -> collect(X::cases())->mapWithKeys(fn (X $x) => [$x->label() => $x->value])
• Delete factory XFactory, replace X::factory() calls with some default X::case1Id()
• Remove eager loading statements ->with('x') from DB queries

[yannik131]

@mzur I've started working on the maia code, but this PR is ready for review. It shouldn't be merged before the maia PR though. Most of the changes are the result of the above migration guide I created for myself. There are a few TODOs scattered through the code, but they could maybe just be removed. And I can't really test the entirety of the application, but the tests pass and the basic things I tried locally (annotations, reports, admin area, ...) worked without issues. I've long been thinking about creating an E2E regression test with something like Cypress for regression cases like this, what is your opinion on that? Just a single test that logs in and tests some basic things (create a project, open image/video annotation tool, create an annotation, generate a report, ...).
I would like to put the enums into a separate Enums/ directory. I just didn't do it yet because it would affect hundreds of files and make the PR difficult to review, so I'll do it last when everything else is settled.

[mzur]

I'm thinking if we switch to this new pattern we could just as well embrace it completely although it may be a lot of work. On the other hand, this could be a lot of work with only marginal performance gains (the performance impact of cached models could be minimal although it saves network roundtrips to the cache). It could be mostly a logical refactor without tangible gains...

Since you already put some work into this: Do you feel the change is worth it? We could still pull the plug before putting even more work into this.

If we go ahead:

I think the cleanest approach would be to rename columns like volumes.media_type_id to volumes.media_type and then use enum casting for this property. This way we don't have to implement custom accessors for every enum property.

Instead of implementing the enums to mimic the old static models (with MediaType::video() or MediaType::videoId() methods, for example) I'd fully switch to enum syntax (i.e. MediaType::VIDEO and MediaType::VIDEO->value). This would require updates to every place a static model was used (including modules).

Let's discuss the high-level comments first. I didn't go into too much detail below.

[mzur]

Maybe also add implements Stringable to the enums?

[mzur]

Regarding E2E integration tests: I'd like to stick with testing the backend/API only because I feel full UI/E2E tests would quickly become a burden to maintain with our little resources. If people start paying for BIIGLE to be reliable in business-critical applications, we can reconsider this.

Besides, since I just noticed this: In the future, please try to align your commit messages to the convention we use.

[yannik131]

@mzur I agree with your suggestions, and I don't think it will take more than a couple of hours to add these other changes. Shouldn't be a problem.
But do feel free to change priorities of issues on the roadmap if you think some issues are more important than others. I always pick issues with higher priority first, and no issue currently has "low" priority.

[mzur]

I think this is not an issue of priorities (besides that "low" issues are basically never worked on), it's more my habit of writing down ideas as issues without always giving much though about gain/effort. So we have issues with medium priority that we definitely need sitting next to issues with the same priority that we should be more careful with. I'm not sure how to deal with it other than asking you to think about implications first and talking to me if you think gain/effort is too low.

P.S.: You find issues with low priority in the full roadmap. The task list is already the version filtered by me.