https://github.com/zombodb/zombodb/blob/master/THINGS-TO-KNOW.md#heap-only-tuples-hot-are-not-supported

https://github.com/zombodb/zombodb/blob/master/TYPE-MAPPING.md

Idea: an additional field for ZomboDBIndex.

https://github.com/zombodb/zombodb/blob/master/INDEX-MANAGEMENT.md#with--options

• django_zombodb version: 0.1.4
• Postgres version: 10.7
• ZomboDB version: 10-1.0.3
• Django version: 2.1.7
• Python version: 3.6.4
• Operating System: Ubuntu 16.04

Description

When we generate migrations, the result is:

migrations.AddIndex(
    model_name='xmodel',
    index=django_zombodb.indexes.ZomboDBIndex(
        fields=['name', 'slug'], 
        name='xmodel_slug_f88d55_zombodb', 
        url='http://127.0.0.1:9200/'
    ),
),

The value of url kwarg should be settings.ZOMBODB_ELASTICSEARCH_URL because on different environments we might have different ElasticSearch URLs. Running migrations in production or staging/qa, will fail because ES has a different URL.

This should be the correct output:

migrations.AddIndex(
    model_name='xmodel',
    index=django_zombodb.indexes.ZomboDBIndex(
        fields=['name', 'slug'], 
        name='xmodel_slug_f88d55_zombodb', 
        url=settings.ZOMBODB_ELASTICSEARCH_URL
    ),
),

Steps to reproduce:

1. Remove whole model from models.py
2. makemigrations
3. migrate
4. migrate back to migration number before deletion
5. Error here:
   django.db.utils.ProgrammingError: type "restaurants_name_016c1c_zombodb_row_type" already exists

For now, solution is to make a custom database backend engine, like https://github.com/SectorLabs/django-postgres-extra. Then, in the custom backend, implement something like SpatialiteSchemaEditor.delete_model.

We won't fix this now since we want an easier to configure API and this is a low impact issue.

http://docs.haystacksearch.org/en/master/searchqueryset_api.html

Related to #10 and zombodb/zombodb#335

Description

On the dependency management part of the Makefile, remember to remove dependencies added to requirements.txt because of Django so you don't pin them as well.

sed '/django==/d' requirements.txt > requirements.tmp; mv requirements.tmp requirements.txt
sed '/# via django$$/d' requirements.txt > requirements.tmp; mv requirements.tmp requirements.txt

zombodb/zombodb#335

https://github.com/zombodb/zombodb/blob/master/QUERY-DSL.md#sorting-and-limiting-results

Related to zombodb/zombodb#345

Description

Say we filter the queryset as shown in the docs

Restaurant.objects.filter(
    name__startswith='Pizza'
).query_string_search(
    'name:Hut'
)

Is that a scalable solution? I suppose I'm asking whether:

• zombodb in effect evaluates that filtered queryset, then sends a list of ids to ElasticSearch in order to filter the potential results (not scalable, as the size of the search query then grows with the number of Pizza*s in the database), or
• does some magic (which in my mind is like creating an effective additional column of relevance which the normal filtered query is then ordered by) such that neither the search query size nor the index complexity increases with the number of things that you filter/exclude?

I'm a bit more used to django-haystack, where in order to achieve this kind of filtering scalably you'd have to have a thing you want to filter against in the search index itself. Excited by the potential of zombodb but needed to check this!

Suggestion

Please could the documentation here include a slightly more in depth note about how those filters are achieved and if it's scalable?

https://github.com/zombodb/zombodb/blob/master/CONFIGURATION-SETTINGS.md