Open lauxley opened 8 years ago
I think EsMultiIndexable way is better. This will not break the already existing functionality and extend the new feature.
How is the process of development? Can I do anything to help?
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.
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).