-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sanitize queries on JSONField in database #20
base: master
Are you sure you want to change the base?
Conversation
keep in mind that the project started while django 1.6 was the most recent version - at this time the json datatype within postgresql was bleeding edge technology - therefore the usage of anyway, I agree that we have to switch to the internal JSONField of Django, but this requires to make Jane compatible with Django 1.9 - currently its based on 1.8 |
can't keep in mind what I don't know, all i see is that it's based on 1.8 as it stands now ;-)
didn't intend to be offensive, just summarizing the current state
Totally clear, I tried to give it a shot but had to give up after working around a couple of issues. Just way too little knowledge about django and the specific setup.. For the time being, I could work around current limitations in the filtering introducing a very ugly negation of the whole |
I can take care of this if we want to do this - it will greatly simplify the whole thing. The only thing to keep in mind that it currently works with django 1.8 which is LTS. The json field was only introduced in django 1.9 which has a fairly short life cycle so somebody will need to take care to update it to newer django versions. |
the JSONField alone is a reason to go for Django 1.9 - also I'm not a big fan of Django LTS versions as upgrading them later is a huge pain |
I've started work on this.. currently this is partially hampered by django/django#6929, the regex filtering doesn't work due to that bug. The patch is super simple, maybe we can work around it somehow.. |
or someone figures out to either update |
or you could just monkey patch the one function I guess |
This should be pretty close to being ready now.. but I'm stuck with some problem in the station index querying.. no clue why this is not working as expected:
|
fdsn stationxml seems to be pretty much untested though, so passing tests don't say much..
somehow still doesn't work, not the slightest idea why, in debugger the simplest queries seem to fail somehow: (Pdb) for i in query: print(i.json['station']) ALTM ALTM ALTM (Pdb) query.filter(json__station__exact='ALTM') [] (Pdb) print(type(query)) <class 'django.contrib.gis.db.models.query.GeoQuerySet'>
a5f9a37
to
5e76d35
Compare
checking for null values in jsonfields is buggy, so work around it as described here using "__contains" query type: https://stackoverflow.com/q/38528516
Tests pass, only some flake8 fails that I don't get locally. I think this is ready for merging after a review by @krischer or @barsch. This removes internal usage of All existing tests pass. Only one test was changed, but I think that it should be changed (also returning The only ugly thing about this PR is that we need to patch Django because of a bug in django <1.11, see 894824c. But the patching seems to work alright, so I think it might be the lesser evil. Also, this PR should enable having nested information in the json field (i.e. dictionaries), which is currently not supported. (CC @bch0w) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't run the tests - but looks much cleaner now
Ok, so I finally found out what's going on with the comma-separated-lists station query.. I thought it never was implemented, but turns out it was, but it never was tested, so I accidentally removed it in this PR. So don't merge yet.. Also I think event queries are completely untested?? |
1 similar comment
Ok, so I finally found out what's going on with the comma-separated-lists station query.. I thought it never was implemented, but turns out it was, but it never was tested, so I accidentally removed it in this PR. So don't merge yet.. Also I think event queries are completely untested?? |
found out there was untested code that was broken by this PR
As I understand, getting filtered sets of data (e.g. events in quakeml) uses django's
QuerySet.extra(where=[...])
with manually built up query strings. This is pretty hard to extend and there's quite a lot of code involved to build those query strings.Django docs mention that..
and..
Maybe I'm missing something but couldn't this part be simplified by using the API on querying
JSONField
s?Also.. django 1.9 now ships
JSONField
, maybe this should be used instead of the additionaljsonfield
dependency?