* Fixesviktorstrate/photoview#8
- Added new property CounterpartPath to Media struct to hold the path to the counterpart JPEG file (if any)
- Added new MediaType method isBasicSupportedisBasicTypeSupported()
- Added new function isFileExists() to minimize the code duplication
* Fixesviktorstrate/photoview#8
- Chaned CounterpartPath definition from string to *string
- Added new helper method FileExtensions()
- Simplified the logic inside scanForRawCounterpartFile() and scanForCompressedCounterpartFile() functions, reducing the code duplication
* Fixesviktorstrate/photoview#8
- Added debug to fileExists() function
* Cleanup fileExists logging
Co-authored-by: viktorstrate <viktorstrate@gmail.com>
In order to prevent SQL injections and , reveal information about the database tables avoid passing MySQL functions as GQL sorting parameters, I refactored the FormatSQL() function.
Additionally, the old approach with using regex to filter the orderBy parameter was not effective and prevented using column.table annotations.
To prepare for video support
Migrate database rename tables and columns:
- photo to media
- photo_url to media_url
- photo_exif to media_exif
- Update api accordingly
That's why I created a new column storing a MD5 hash of the path and made it unique. The MD5 hash has only 32 characters and can be generated natively in MySQL and MariaDB. It helps us to avoid maximum key length and in the same time enforce unique photo and album paths.
- Added path_hash column to photo and album tables
- Added down migration file for 005_utf8_migration (just for consistency)
- Added PathHash field to Album and Photo struct
- album_scanner.go and photo_scanner.goo perform checks by MD5 hash now
viktorstrate