booxter / letsrolld Goto Github PK

Before touching the database, we should probably make a check that what external apis return returns expected format.

Can be useful to answer questions about new additions.

There's some common logic in different resource types (e.g. using multiplier = 1 as a base), that should be extracted into general machinery.

Steps to implement

• activate flox environment.
• make install
• make init_db && populate
• make webapp
• run a CLI client against the webapp and confirm it returns something sane. (TODO: need to implement the client first)

Postgres will do probably.

Preferences can be pulled from e.g. goodreads.

Note: the size of the database may be enormous because the high number of books, comparing to e.g. movies.

These are redirects and should be avoided to save http requests.

Make sure all resources are updated once in a while.

Right now, the assumption is that I have the full list of directors; I may not (esp. as new directors are born). I should try to find new ones somehow, e.g. by following paths from other crew members (first just other directors, but paths through actors and other staff is probably more promising, since directors don't usually work together; but actors do.)

Preferences can be extracted from services like spotify or last.fm. Information about releases can be extracted from RYM.

Right now, updated_at is always bumped, which makes directors never actually update. updated_at should be only updated when the actual update happened; we may need a separate field to track check timestamps. (Alembic integration is needed for proper db migration.)

The page would consume a config (first global, then per-profile) and produce report page. The report generation should be independent of representation so that I can later generate e.g. emails of the same.

This media state can later be used to adjust recommendations according to what the user owns already.

This would probably build on top of RAG extractor that would consume markdown knowledge base (tracked elsewhere).

On director update, a movie may be detached from a director; or perhaps moved to a new text-slug. In this case, the old record is left in the database. This should be cleaned up.

• flox build is not a thing
• populate only creates directors; need to run-all after it to populate films / offers / ...

Right now these are

    "cli-color-py",
    "simple-justwatch-python-api",

The former is not needed except in recommend script that is obsolete; the latter is already kinda forked and we should probably just ditch it and have something in-house to talk graphql.

This is not going to be just about movies or Letterboxd, probably. Perhaps better to do the rename earlier.

The script handles more than just directors now.

sqlite is not very flexible, and it may be useful to keep htmls as files for further processing in this or other projects.

Since the cache is already in sqlite db, I'll need to migrate it from there.

This is a meta ticket. I would have to resolve a number of issues before I can proceed. E.g. authN, security, scale etc. This is aspirational for now.