Hi Cam, Sent from my iPhone
On Jan 20, 2012, at 11:19 AM, "Cameron Goodale" <[email protected]<mailto:[email protected]>> wrote: I think between Ricky, Rishi and Paul R a Java mongoDB catalog is on the horizon. I would imagine the setups would be similar to the jdbc connection settings (URI, port, username, etc...). The real oddity I see is the db will have a dynamic schema. For my use case I would use a (python) Driver to Query the catalog instead of going through FileManager via XML-RPC. FM already has use cases for this since its Lucene Catalog is basically nosql like mongo so we can follow a similar model. The power of the schema-free collection means you could potentially throw nested metadata (documents) into mongo without ever defining policy, which could potentially mean no need to restart if you throw in a new doc/metadata schema since the underlying catalog doesn't care. Policy is important in the OODT context (think met extractor definitions as an example) but yes we can make it transparent to mongo and to the OODT user. There is still so much we need to consider from how to declare indexes, replica sets, etc....but it seems like a worth while effort given how often people want to query the catalog to drive web UI's from graphs to maps. Yep! Cheers, Chris (who now loves open source law) -Cam On Thu, Jan 19, 2012 at 7:05 PM, Mattmann, Chris A (388J) <[email protected]<mailto:[email protected]>> wrote: Super +1! Sent from my iPhone On Jan 19, 2012, at 6:28 PM, "Nguyen, Ricky" <[email protected]<mailto:[email protected]>> wrote: > MongoDB? Haha > > Sent from my iPhone > > On Jan 18, 2012, at 6:54 PM, "Mattmann, Chris A (388J)" > <[email protected]<mailto:[email protected]>> wrote: > >> Right now all the keys must be defined in elements.xml (per the >> XMLValidationLayer). There has been discussions of any one >> (or all of the following): >> >> 1. config option in XMLValidationLayer to simply accept all provided >> metadata. Config option would appear in filemgr.properties >> properly namespaced, and read in the XMLValidationLayerFactory. >> 2. a new ValidationLayer would be created (AcceptAllMetValidationLayer) that >> did the same thing as #1, but without a config >> option, and the need to officially "change" the selected ValidationLayer >> extension point. >> 3. the addition of (similar to Apache Solr) the ability to read '*' fields, >> or regex fields, and to specify those in elements.xml, either >> as (a) an addition to the XMLValidationLayer [with config options]; and/or >> (b) a new ValidationLayer with the ability to read its >> own form of elements.xml with those types of Fields. > > > > --------------------------------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, > is for the sole use of the intended recipient(s) and may contain confidential > or legally privileged information. Any unauthorized review, use, disclosure > or distribution is prohibited. If you are not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of this original > message. > > --------------------------------------------------------------------- >
