ChristopherRabotin
commented
9 years ago That's actually a good catch. I'll check the coverage tests which I added in just the other day to see how that wasn't caught in these.
As for your participation on this project, I really hope it's not over! You've contributed a lot or quality code and it's been a pleasure to see that people are using and contributing to this package.
I should be able to get those PRs dealt with quickly since I have a bit of spare time this week (hence my contributions to another open-source Web framework called Gin in Go). I'll check out your celery signal processor, we might even use it at Sparrho (we have a bit of a dodgy way to use celery with bungie search to make sure things are in sync).
This will be one of a series of 2 or 3 PRs coming in today, and they will be my last of this summer. I would really appreciate if you could merge these and put out a release of bungiesearch by the end of the day on Friday - these are really tying up loose ends rather than major features. It's been a pleasure working with this project! I also wrote a celery signal processor for bungiesearch this summer as well, and you can check that out here: https://github.com/afrancis13/celery-bungiesearch. Feel free to take a look and use it/recommend it if you see a situation that fits the use case. I will make a second release of this as soon as the newest version of bungiesearch is released. Thanks for everything!
Previously, on update: if hasattr(src.get_model_index(model_name), 'indexing_query')
Of course, this is never True, because 'indexing_query' never gets put on the model index, so you would need to do something like: if hasattr(src.get_model_index(model_name).Meta, 'indexing_query')
However, to keep consistent with the project, I abstracted the detail of this into the indices.py document with _meta.