Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend databroker-unpack to load documents into Mongo #7

Closed
danielballan opened this issue Apr 6, 2020 · 2 comments
Closed

Extend databroker-unpack to load documents into Mongo #7

danielballan opened this issue Apr 6, 2020 · 2 comments

Comments

@danielballan
Copy link
Member

For many use cases, running intake top of a directory of mspgack or jsonl files is not suitable. The databroker-unpack utility should provide an option to copy Documents from the files into MongoDB and auto-generate a suitable catalog file.

I didn't do this in the first pass because it was not obvious to me how to spell, or how we might want to extend it. Initial thought:

databroker-unpack inplace DIRECTORY NEW_CATALOG_NAME  # current functionality

and

databroker-unpack mongo_normalized DIRECTORY NEW_CATALOG_NAME --metadatastore=MONGO_URI --filestore=MONGO_URI

Now, databroker-pack is intentionally "opinionated" and only supports a hard-coded subset of suitcases (msgpack, jsonl). Should we do the same for -unpack? I think so, because it enables us to auto-generate a working catalog file.

@tacaswell
Copy link
Contributor

Maybe a --merge flag that will try to insert into an existing catalog (rather than creating a new one). You can imagine having behind the scenes logic to sort out if we can side-load (ex msgpack -> msgpack) by just copy files, but fallback to db_new.insert(...).

We probably need a set of helpers for creating new catalogs (of what ever backing) and dumping the config files in the correct place.

@danielballan
Copy link
Member Author

Both done in #16

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants