Added search to the api, and postgres support for DB #166
Conversation
screenshots saved in postgres
Gallery and Detail screenshots load from DB
removed accidental binary upload
|
@habitualdev sorry for taking so long on this one. could you rebase this pr perhaps? I also want to suggest we dont add another flag, but rather, parse a URI scheme to determine the database type to use. Eg. |
Yeah, I can do that. I'll spiff it up and rebase. What do you think about storing the screenshots in the DB as well? I ended up adding it on my fork to just keep everything together. |
Amazing. I'm hoping to cut a new release today as well :)
I think we can add this as a flag for those that would want that maybe, keeping the original filesystem storage behaviour as default. I think most use this vs the reporting server so that they can use any tool to flick through screenshots (or process them further using other tools). |
* Change database screenshot saving to be flag controllable * Remove platform selection flag and instead rely on URI parsing * Add check to prevent empty search api query string * Display screenshots from db if available, otherwise fallback to fs
|
Thanks for the PR! I made some tweaks in 62d6de3. |
I plan on using this at a larger scale, one where it would be good to have an externally accessible database, as well as a search handler being added to the API.
Took advantage of the existing gorm usage to add a simple flag to point to a postgresql DB (confirmed working with both local and remote servers). As of now takes a fully qualified PSQL DSN. Database type is switched with the "t" flag. SQLite remains the default, changing type to "1" allows using postgresql.
Example Command:
Mostly cloned the existing search handler behind the UI, and just returning the JSON.