Django has allowed partial indices for a while now. I’ve seen examples where it’s set on boolean and strings, but what if I want to set it on a date, for example > 01-01-2023? Engine is PostgreSQL.
Related
We recently switched from MongoDB to TokuMX. In one collection our documents all have a numerical filed, "docType". Some documents have a field "DL_Number", and others don't. For those documents with a "DL_Number" field, the combination of "docType" and "DL_Number" should serve as a unique index.
Using C++ Legacy, we originally created an index like this:
mongo::IndexSpec().addKey("docType").addKey("DL_Number").unique().partialFilterExpression(BSON("DL_Number" << BSON("$exists" << true)));
What we were going for was an index where "docType" and "DL_Number" would provide a unique key for documents that had a field "DL_Number".
The statement worked find in MongoDB, but now that we've switched to TokuMX, the partial filter doesn't work any more. Trying to insert the second document without a "DL_Number" field throws an exception.
Has anybody else had this problem with TokuMX? Were you able to find a work-around?
Partial indexes are a MongoDB 3.2 feature, but TokuMX is based on MongoDB 3.0, so this MongoDB feature is not available with TokuMX.
I am writing a simple app in django that searches for records in database.
Users inputs a name in the search field and that query is used to filter records using a particular field like -
Result = Users.objects.filter(name__icontains=query_from_searchbox)
E.g. -
Database consists of names- Shiv, Shivam, Shivendra, Kashiva, Varun... etc.
A search query 'shiv' returns records in following order-
Kahiva, Shivam, Shiv and Shivendra
Ordered by primary key.
My question is how can i achieve the order -
Shiv, Shivam, Shivendra and Kashiva.
I mean the most relevant first then lesser relevant result.
It's not possible to do that with standard Django as that type of thing is outside the scope & specific to a search app.
When you're interacting with the ORM consider what you're actually doing with the database - it's all just SQL queries.
If you wanted to rearrange the results you'd have to manipulate the queryset, check exact matches, then use regular expressions to check for partial matches.
Search isn't really the kind of thing that is best suited to the ORM however, so you may which to consider looking at specific search applications. They will usually maintain an index, which avoids database hits and may also offer a percentage match ordering like you're looking for.
A good place to start may be with Haystack
In my application I use time zones (USE_TZ=True) and all the dates I create in my code are aware UTC datetime objects (I use django.util.timezone.now for the current date and the following helper function to ensure all the dates in my instances are what I expect:)
#classmethod
def asUTCDate(cls, date):
if not timezone.is_aware(date):
return timezone.make_aware(date, timezone.utc)
return date.replace(tzinfo=timezone.utc)
I also enforced the check of naive/aware dates using this snippet (like suggested in the doc):
import warnings
warnings.filterwarnings(
'error', r"DateTimeField .* received a naive datetime",
RuntimeWarning, r'django\.db\.models\.fields')
As I understood so far, this is the right way to proceed (this is a quote from the django documentation: "The solution to this problem is to use UTC in the code and use local time only when interacting with end users."), and it seems that my app is handling dates very well… but I have just implemented a filter against a model that makes use of the Django 1.6 __hour and it force the extraction based on the user timezone, the result is something like:
django_datetime_extract('hour', "object"."date", Europe/Rome) = 15
but this breaks my query, since some results I was expecting are not included in the set, but when I use a __range to search between dates it seems to work as expected (objects with a date in the range are returned)… so it seems to me that Django takes into account timezones in queries only for the __hour filter… but I don't understand why… I was supposing that UTC is used everywhere except in templates where the displayed dates are formatted according to user tz, but maybe that's not true.
So my questions are: is the way I'm working with time zones right? Is __hour filter wrong or what?
It seems as though you're doing the right thing with dates. However, all the documentation for any date related functionality, such as filtering by hour include this note:
When USE_TZ is True, datetime fields are converted to the current time
zone before filtering.
For the range filter, this note doesn't exist because range can be used to not only filter on dates, but other types as well such as integers and characters. ie It is not necessarily datetime aware.
In essence the problem comes down to this: where do you draw the line between 'interacting with users' where times are in a local timezone, and what is internal where times are in UTC? In your case, you could imagine a user entering in a search box to search for hour==3. Does that mean for example that your form code should do the conversion between hour==3 and the UTC equivalent? This would then require a special forms.HourField. Or perhaps the value (3) should be fed directly to the query where we know that we're searching on an hour field and so a conversion is required.
We really have to follow the documentation on this one.
Values which are going to be filtered against date/time fields using any of the specialised date/time filtering functions will be treated as being in the user's local time zone.
If using the range filter for dates no time conversions occur so you are expected to convert the user's entered local time value to UTC.
I'm using Django-Haystack with ElasticSearch.
I will need to have Faceting.
The Django-Haystack documentation says:
You generally create a unique SearchIndex for each type of Model you wish to index, though you can reuse the same SearchIndex between different models if you take care in doing so and your field names are very standardized.
My doubt is, to get faceting working I can use one index per Model or I must to create a unique index?
You can have multiple index classes, but each of them should have the field you will be faceting on.
I'm currently trying to query the facebook api to retrieve some data via batch-requests with two fql queries.
One of the queries fetches a set of album ids in the form of:
Select aid FROM album WHERE ...
While the other one tries to retrieve photos for the found albums:
SELECT ... FROM photo WHERE aid IN ({result=album_ids:$.*.aid})
Where 'album_ids' is the name of the first query.
Most of the time this works perfectly but sometimes a album comes along with an aid containing a '_' - Which would be perfectly fine since the documentation specifies the aid as string.
However the jsonpath in the second query does not quote the ids according to the facebook api:
Parser error: unexpected '_xxxxx' at position xx
...
SELECT ... FROM photo WHERE aid IN (10000xxxxxxxxxx_xxxxx)
The json result for the first query clearly has them quoted:
[{\"aid\":\"xxxxxxxxxxxxxxxxxxx\"},{\"aid\":\"10000xxxxxxxxxx_xxxxx\"},...]
Am i missing something here or does facebook wrongly skip to quote the ids in the second query even though they are clearly strings.
As far as i see in the facebook-api and jsonpath specs this should be working.
Or is there a work-around to get this to behave as expected? (Except of doing the quoting client-side and with two seperate requests).
Right now i'm trying to change my query as suggested here: Quoting/escaping jsonpath elements for in clause of dependent fql queries
But maybe there is a way without completely re-structuring the queries itself.