Closed dorodere closed 1 year ago
Rough todo:
Short note so I don't forget it: pretty_date
in the drives panel code is not needed anymore.
@Nitro-paul Be advised, I need to write a registration count function in sql_interface
anyways in order to implement the registration cap. Which I'd do as the next thing, and would mean you could just use that one instead of crafting your own one.
Should I build it and you rebase your branch and use mine? Or should I wait for/help you and tackle other stuff like #23 or #24 in the meantime?
Thats a good idea, you writing that function would probably have good impact on development time and i would happily use your funcion wich will most likely be more eficient. Only things i need to know will be function name and minor details about the returned value.
It's not about efficiency, but rather about you learning something :D I believe you could indeed learn a lot about SQL and how to use rusqlite here. How about this?
cap-registrations
branch containing a function you could use.This will be the signature:
pub fn count_registrations(conn: &mut rusqlite::Connection, drivedate: chrono::NaiveDate) -> Result<u32, rusqlite::Error>
fwiw the query is up on the cap-registrations
branch
Actually implementing the backend logic for moving a drive into the "inaccessible" section turns out to be more interesting. I wanted to include a subquery in the general registrations-per-person query for the dashboard which would be basically count_registrations
, but that turned out to be a whole jungle I'm not sure I want to execute on every single index call.
I have to sleep about this. Maybe you were right about keeping the current registration count in a new column on the drives.
Alright, I'll do this transparently in the sql_interface by adding a new column registration_count
. Not really feeling like doing cursed nested subqueries atm.
wait count
with an OVER
clause seems interesting
Nevermind, rolling back. Manually caching the registration count that currently points to this drive has a way too large surface for bugs and introduces many additional queries just to keep the field valid and correct. The subquery isn't that bad.
Alright, I'm pretty much done. I only need to implement being able to unregister after having registered/only displaying a drive in the locked section if the registration intention would to register, but that's not yet.
...something's terribly broken on the superuser drives panel. But not today.
Nevermind, probably joins are trolling me instead.
Turns out, NULL < 2
is nothing, so NULL
again.
Sometimes the service might not have the bus with 1337 seats available, but only the one with 50 seats. Of course then not more than 50 people should register.
After some back and forth, we've decided that this should go on a first-come first-served basis: If you've registered early enough for the drive, you're in. Else, if the limit is already reached, your registration is denied and an error pops up.
Partly linked to #2, since this must be both configurable as in
the second overriding the first. Not sure if this configuration should happen in the web UI or in
Rocket.toml
, first one would require a whole new table.