* Remove existing installations with msi installer
* Remove unused x86 wxs file
* Uninstall old msi versions with different upgrade code
* Progress but error 2721 happens on install
* Remove added uninstall previous version wxs stuff
* Use revision as patch number
MSI only uninstalls previous versions in case the version number changed (it only checks the first three numbers (major, minor, patch)).
Thus, to prevent each preview install to result in it getting registered as a new "app" and for it to uninstall the old versions, we have to change the version on each release.
* Deprecate "BuildConfig.REVISION"
* Remove outdated env vars
---------
Co-authored-by: Syer10 <syer10@users.noreply.github.com>
* Log exceptions during graphql execution
Exceptions got swallowed by graphql
* Add stack trace to error in graphql response
Depending on the exceptions error message, the error in the response might be quite useless (e.g. "Stub!" error in android classes)
The update subscription emitted the full update status, which, depending on how big the status was, took forever because the graphql subscription does not support data loader batching, causing it to run into the n+1 problem
* Initial import of Kitsu tracker
Based on Mihon 6c6ea84509cc1bd859c880bebbc69067a241b358 because its
successor 9f99f03 relies on incompatible changes
* Kitsu: Avoid stupid long/int cast
* Optimize restoring manga chapters
* Streamline restoring manga data
* Optimize restoring manga trackers
* Simplify passing manga category restore data
* Properly prevent mangas from getting added to default category
76595233fc never actually worked...
* Extract logic to add manga to categories from gql mutation
* Optimize restoring manga categories
* Optimize restoring categories
coerceIn throws an error in case the max value is less than the min value ("Cannot coerce value to an empty range: maximum <max> is less than minimum <min>")
Regression from c8bd39b4bf
* Extract logic to restore manga chapters into function
* Extract logic to restore manga categories into function
* Extract logic to restore manga trackers into function
* Handle duplicated chapters in backup
In case a backup contained duplicated chapters for a manga, the manga failed to restore since the ChapterTable has a unique constraint to prevent multiple chapters with the same "url" and "mangaId"
* Añadiendo algunos cambios iniciales para probar OPDS
* Add suport to OPDS v1.2
* Added support for OPDS-PSE and reorganized controllers
* Rename chapterIndex to chapterId in the API and controller, and update descriptions in OPDS
* Refactor OPDS to use formatted timestamps and proxy thumbnail URLs
* Refactor OPDS to use formatted timestamps and proxy thumbnail URLs
* Update Manga API to download chapters cbz using only chapterId and improve chapter download query
* Optimize OPDS queries
* Update Manga API to download chapters cbz using only chapterId and improve chapter download query
* Optimize OPDS queries
* Use SourceDataClass to map sources and optimize thumbnail URL retrieval
* Kotlin lint errors in ChapterDownloadHelper and Opds
* Kotlin lint errors in ChapterDownloadHelper and Opds
* Refactor OPDS API endpoints and rename OpdsController to OpdsV1Controller
* Translate OpdsV1Controller comments to English and remove unused imports
* Translate comments in OpdsAPI.kt to English
* Add SearchCriteria class and update OpdsV1Controller
* Remove spanish comments
* Refactor search handling in OpdsV1Controller and update search feed endpoint
* Fix search
* Añadiendo algunos cambios iniciales para probar OPDS
* Add suport to OPDS v1.2
* Added support for OPDS-PSE and reorganized controllers
* Rename chapterIndex to chapterId in the API and controller, and update descriptions in OPDS
* Refactor OPDS to use formatted timestamps and proxy thumbnail URLs
* Refactor OPDS to use formatted timestamps and proxy thumbnail URLs
* Update Manga API to download chapters cbz using only chapterId and improve chapter download query
* Optimize OPDS queries
* Update Manga API to download chapters cbz using only chapterId and improve chapter download query
* Optimize OPDS queries
* Use SourceDataClass to map sources and optimize thumbnail URL retrieval
* Kotlin lint errors in ChapterDownloadHelper and Opds
* Kotlin lint errors in ChapterDownloadHelper and Opds
It's possible that a manga is bound to a tracker while there is no search result.
This happens when e.g. restoring a backup which includes track bindings for which there was never a tracker search.
In that case when trying to e.g. copy the binding to another manga, the mutation would fail due to not finding a search result.
These cases can be handled by additionally checking the TrackRecordTable to get the necessary track info.
* Update to exposed-migrations v3.5.0
* Update to kotlin-logging v7.0.0
* Update to exposed v0.46.0
* Update to exposed v0.47.0
* Update to exposed v0.55.0
* Update to exposed v0.56.0
* Update to exposed v0.57.0
* Update graphqlkotlin to v8
* Go back to JsonMapper
* Add context to data loaders
* Compile fixes
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Syer10 <syer10@users.noreply.github.com>
* Properly set download update type on exceptions
* Always send FINISHED download update to client for deprecated subscription
By the time the status was sent to the client, the finished download item was already removed from the queue, causing the client to never get the latest status, thus, having an outdated cache
Regression introduced with 168b76cb0c
* Validate setting values on mutation
* Handle invalid negative setting values
* Ensure at least one source is downloading at all times
* Prevent possible IllegalArgumentException
The "serverConfig.maxSourcesInParallel" value could have changed after the if-condition
* Emit only download changes instead of full status
The download subscription emitted the full download status, which, depending on how big the queue was, took forever because the graphql subscription does not support data loader batching, causing it to run into the n+1 problem
* Rename "DownloadManager#status" to "DownloadManager#updates"
* Add initial queue to download subscription type
Adds the current queue at the time of sending the initial message.
This field is null for all following messages after the initial one
* Optionally limit and omit download updates
To prevent the n+1 dataloader issue, the max number of updates included in the download subscription can be limited.
This way, the problem will be circumvented and instead, the latest download status should be (re-)fetched via the download status query, which does not run into this problem.
* Formatting
