After a bit of work to minimize the cases where sqlparse would be a
required at runtime for SQLite to AddConstraint/RemoveConstraint operations
[0] I came to the conclusion that it would make more sense to make sqlparse
an hard dependency of Django 2.2.
The two reasons backing this conclusions
Week ending October 27, 2018
Triaged
---
https://code.djangoproject.com/ticket/29881 - Invalid SQL on MySQL with
Cast to DecimalField (duplicate)
https://code.djangoproject.com/ticket/29890 - FileSystemStorage._save()
doesn't catch FileExistsError on concurrent os.mkdirs() (accepted)
A
Django's F objects does not perform JSON lookups. A ticket has been raised
for the same https://code.djangoproject.com/ticket/29769
I have written a customer expression for querying JSONField and
* it works!*
class KeyTextTransformFactory:
def __init__(self, key_name):
self.key_name
Djello is nice, bookmarked!
On Sat, 27 Oct 2018 at 02:50, Collin Anderson wrote:
> A few years ago I realized I really liked the UI of Trello.com, so I tried
> creating a trello-style view of django tickets:
>
> https://djello.collinand.org/ (beware, I'm not a designer :)
>
> It's basically just
Hi,
as far as I understand the documentation[1], django's architecture
supports object permissions, but external apps like django-rules or
django-guardian are supposed to provide actual implementations.
I think this approach is great. However, I believe that there are some
key points where django
Collin,
Are you using an inverted index (search engine) behind that for relevance
ranking, better word segmentation/stemming/synonyms, and peirformance?
I think that something like that is really needed when the problem is
finding stuff.
On Friday, October 26, 2018 at 9:50:43 PM UTC-4, Collin