| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
import refactors and deprecations
Some of these are from old stale branches (the datacite subject metadata patch), but most are from yesterday and today. Sort of a hodge-podge, but the general theme is getting around to deferred cleanups and refactors specific to importer code before making some behavioral changes.
The Datacite-specific stuff could use review here.
Remove unused/deprecated/dead code:
- cdl_dash_dat and wayback_static importers, which were for specific early example entities and have been superseded by other importers
- "extid map" sqlite3 feature from several importers, was only used for initial bulk imports (and maybe should not have been used)
Refactors:
- moved a number of large datastructures out of importer code and into a dedicated static file (`biblio_lookup_tables.py`). Didn't move all, just the ones that were either generic or very large (making it hard to read code)
- shuffled around relative imports and some function names ("clean_str" vs. "clean")
Some actual behavioral changes:
- remove some Datacite-specific license slugs
- stop trying to fix double-slashes in DOIs, that was causing more harm than help (some DOIs do actually have double-slashes!)
- remove some excess metadata from datacite 'extra' fields
|
| | |
| |
| |
| |
| | |
Use datacite-specific wrapper function, and remove a couple
non-OA/TDM-limited licenses.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
- MAX_ABSTRACT_LENGTH set in a single place (importer common)
- merge datacite license slug table in to common table, removing some
TDM-specific licenses (which do not apply in the context of preserving
the full work)
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Cleaning out dead code.
These importers were used to create demonstration fileset and webcapture
entities early in development. They have been replaced by the fileset
and webcapture ingest importers.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Many of these 'subject' objects have the equivalent of several lines of
text, with complex URLs that don't compress well. I think it is fine we
have included these thus far instead of parsing more deeply, but going
forward I don't think this nested 'extra' metadata is worth the database
space.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This was used during initial bulk imports, but is no longer used and
could create serious metadata problems if used accidentially.
In retrospect, it also made metadata provenance less transparent, and
may have done more harm than good overall.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fatcat metadata cleanups/fixups, November 2021
Three cleanups implemented in this branch:
- update non-lowercase DOIs on releases (couple hundred thousand entities)
- fix incorrectly imported file/release pairs, on the file entity side (~250k entities)
- expand truncated wayback URL timestamps in file entities (up to 10 million entities)
Instead of proposals, there are documents for each cleanup in `notes/cleanups/`.
Have done spot testing of tens of thousands of entities each in QA, and confident about running in production.
Plan is to run updates in the order above. DOI and bugfix updates will go fairly fast; the wayback timestamp updates will go slower, and result in large re-indexing load both in fatcat and scholar, because both release and work entities will get triggered for update when file entities are updated.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | |/ |
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
| |
The intent of this change is to start updating Pubmed metadata records
when a PMCID has been assigned, but that ext_id hasn't been recorded in
fatcat yet.
It is likely that this change will result in some additional duplicate
PMCIDs in the catalog. But the principle is that the PMID is the primary
pubmed identifier, and all records with a PMID should have the PMCID
that pubmed indicates, even if there exists another incorrect record.
|
| | |
|
| |
|
|
|
|
|
| |
In a couple cases (eg, filesets), had made tests agnostic to sort order,
because the sort order was not stable.
In other cases, simply small cleanups and comment improvements.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The hope is to make things like file entity URLs, fileset manifests, and
other arrays in the JSON API "stable", meaning that if you create an
entity with a list of a given order, a read back (in any environment,
including prod/QA, bulk dumps, etc) will return the array with the same
sort order.
This was informally happening most of the time, but occasionally not (!)
Assumption is that these sorts will have little or no performance
impact, as the common case is less than a dozen elements, and the hard
cases are a few thousand at most, and there is already a sorted index.
|
| | |
|
| |
|
|
| |
base class)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Minor issue. Caught by type checking
|
| |
|
|
| |
This was caught by new linting, I think not caused by any recent changes
|
| | |
|
