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

Multiple indices for a single model #46

Open
lauxley opened this issue Jun 1, 2016 · 3 comments
Open

Multiple indices for a single model #46

lauxley opened this issue Jun 1, 2016 · 3 comments

Comments

@lauxley
Copy link
Contributor

lauxley commented Jun 1, 2016

A very common use case is to store different languages for translatable models in different indices (cf https://www.elastic.co/guide/en/elasticsearch/guide/current/one-lang-docs.html).

The main problem is to choose between a new class EsMultiIndexable(?) with the corresponding manager, or a non backward compatible change of the api of EsIndexable (index -> indices, etc).

@onegreyonewhite
Copy link
Contributor

I think EsMultiIndexable way is better. This will not break the already existing functionality and extend the new feature.

@onegreyonewhite
Copy link
Contributor

How is the process of development? Can I do anything to help?

@lauxley
Copy link
Contributor Author

lauxley commented Jun 29, 2016

Hi, the development is on pause right now on my side, i will get back to it sometime during the summer but help is always very appreciated !
A few people talked about the python3 compatibility but nobody pushed anything and i think it should be the main priority alongside the django 1.9 compatibility (but this one is only a matter of doing some integration testing with real applications).

If you are interested in this issue in particular you can just implement a proof of concept and we will talk about it. I have to admit though that I'm a little bit more inclined to go with the non backward compatible change, this package is not yet released for this exact reason - some things are not yet set in stone and i want the API to be as simple and pythonic as possible, if we had another layer it will make everything more complex, including the documentation.

If you want something a little bit more manageable i think the elasticsearch2.0 (#28) support should be easier to start with, or you could take a look at #32 which is almost done but requires a bit of hacking.

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