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

Already on GitHub? Sign in to your account

Removing the "subdocument criteria"-feature? #23

ahx opened this Issue May 24, 2014 · 5 comments


None yet
2 participants

ahx commented May 24, 2014

I am trying to build a very basic Elasticsearch adapter, but then i noticed Pupa::Person#fingerprint and that "subdocument criteria"-feature via $or.
Since PostgreSQLAdapter does not support subdocument criteria, how would you feel about about remothing that feature, since it makes implementing custom adapters much more difficult?


jpmckinney commented May 24, 2014

Subdocument criteria are criteria with keys like other_names.name; PostgreSQLAdapter ignores the other_names.name part of the Organization and Person fingerprints. To support such criteria, the adapter would have to join tables - which is something I can implement eventually. The $or is not a problem for PostgreSQLAdapter, it just transforms it into an OR statement.

ElasticSearch has an or filter that looks a lot like the MongoDB query. That page has examples of querying subproperties / subdocuments like name.first.

I'm not sure what features ElasticSearch is missing that would make implementing an adapter difficult?

ahx commented May 24, 2014

Currently the PostSQLAdapter ignores the $or.
Is the $or notation coming from some sort of standard query language or is a specific Mongo feature that which adapter authors would need to port to custom adapters?
Implementing $or should be possible with Elasticsearch and PG, but in case the $or notation does not follow any standard query syntax i think it should be removed or changed.


jpmckinney commented May 24, 2014

That's not what that line of code means... It's passing the $or array to reject_subdocument_criteria, which removes keys like other_names.name.

Pupa was originally MongoDB-only, so it used MongoDB-specific features.

I don't know of any standard query language to substitute. SQL is way more complex that MongDB syntax. Do you have a suggestion for an alternative query language, expressible in plain Ruby?

ahx commented May 24, 2014

Ok i see. I have overlooked the Sequel .or.

My first though was SPARQL, since it seems to be relevant to the domain but i think it would be overkill for now and definitily would make things (implementing custom adapters) even harder. I would like to find a simple standard (not Mongo specfic) syntax, but i understand that the feature is useful.
Do you think adding a custom adapter is useful using the custom feature set (including the $or syntax) or do you think that Pupa is best used with Mongo?


jpmckinney commented May 25, 2014

The $or syntax is only used by the Membership, Person and Organization models, and you can override the fingerprints if necessary by reopening the classes. Indeed, the default fingerprints may be inadequate depending on the use case, even if you were to stick to Mongo. I don't think there are any other parts of the code that are Mongo-specific.

I would be happy to merge an ElasticSearch adapter, or help work on one.

@ahx ahx closed this Jun 1, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment