feat(metadata): use a GoogleBooks archive identifier for the Google Books lookup - #587
feat(metadata): use a GoogleBooks archive identifier for the Google Books lookup#587mbret wants to merge 3 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f41f975b7c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| freshFileMetadata?.googleVolumeId ?? | ||
| reusedFileMetadata?.googleVolumeId |
There was a problem hiding this comment.
For an existing book whose type: "file" metadata was extracted before this field existed, an unchanged provider timestamp and size cause the download to be skipped and reusedFileMetadata cannot contain googleVolumeId. Consequently, every ordinary scheduled or manual non-force refresh continues using the ISBN/title lookup and never discovers the embedded GoogleBooks identifier; only changing the file or selecting a hard refresh repairs it. Version the extraction cache or arrange a one-time re-extraction for cached entries that predate this field.
Useful? React with 👍 / 👎.
5531e88 to
89f4716
Compare
89f4716 to
ccc3cff
Compare
…ooks lookup An archive that carries a `GoogleBooks` identifier already resolves it — the lookup just never looked. `FileMetadata` now advertises `googleVolumeId`, the archive extractor reads it, and the single Google Books lookup falls back to it after the filename directive, mirroring the existing ISBN chain (there is no user-editable volume id to sit in front). A volume id names one edition, so this is a more precise lookup key than a title and than an ISBN shared across printings. The existing preference order inside getGoogleBookMetadata is unchanged: an ISBN still wins over a volume id when a book has both. Only the bare `GoogleBooks` scheme is recognised. A catalog URL such as `books.google.com/books?id=…` — which is how ComicInfo `<Web>` would carry the same reference — is left for the crosswalk that needs @prose-reader/metadata-fetcher. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A volume id addresses one Google Books record; an ISBN can match several printings of the same work, so the record it lands on is a coin toss between editions. Where both are known, the volume id is the better key for this API. Only the Google Books lookup order changes. ISBN remains the priority identifier in the source chain that decides which metadata wins. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The file variant advertises it now, so the example contradicted the type it was documenting. No field is variant-less any more, so the merged view is described without one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ccc3cff to
0e4cb7b
Compare
1 participant
Follow-up to #586, which added the UI and archive-writing side. That PR lets you store a Google Books volume id in a book; this one makes oboku act on it.
Independent of #586 — no overlapping files, and an EPUB tagged by another tool can already carry a
GoogleBooksidentifier today. Mergeable in either order.What
resolveArchivealready reports aGoogleBooksidentifier from the OPF; the metadata pipeline just never looked at it.FileMetadataadvertisesgoogleVolumeIdgetMetadataFromArchivereads it off the resolved identifiers[oboku~google-volume-id~…]filename directive, mirroring the existing ISBN chain (no user-editable volume id exists to sit in front of the directive)Volume id now wins over ISBN — for this API only
A volume id addresses one Google Books record. An ISBN can match several printings of the same work, so which record it lands on is effectively a coin toss between editions. Where both are known, the volume id is the better key, so
getGoogleBookMetadatanow tries it first.Scoped deliberately: this is the lookup order inside the Google Books provider. ISBN remains the priority identifier in the source chain that decides which metadata ultimately wins for a book.
Comics work too
identifierValue(metadata.identifiers, "GoogleBooks")comes straight from archive-reader 1.357.0 and reads the id out of a catalog link as well as an explicitly typed identifier — so a comic, whose only reference field is ComicInfo'sWeb, is picked up too. That was the one gap when this PR was first opened, and it closed without needing #586's helper: the crosswalk moved upstream in prose-reader#326 and the hand-rolled scheme check here is gone.Verification
getMetadataFromArchive(identifier present, absent, and not confused by an ISBN or a catalog URL)apps/web297 tests,packages/shared113 tests passtscclean inapps/api,apps/web,packages/shared; biome cleanOne gap worth knowing: the lookup-order change itself is not covered by a test.
getGoogleBookMetadataimportssrc/lib/google/googleBooksApithroughapps/api'sbaseUrl, which the repo's vitest setup can't resolve (there is no vitest config, and jest only picks up*.spec.ts), so the module can't be imported from a test at all today. Adding that alias config would make this and the rest ofapps/api/src/libtestable — happy to do it as its own PR.🤖 Generated with Claude Code