Why HStore and not JSON(B)?
si14 opened this issue · 4 comments
Do you think it's reasonable to migrate the library to JSON(B) in a long term?
On one hand using HStore makes a lot of sense as it's the simplest data type available in Postgres that does the job. However, JSONB is composable. That is, one can store JSON in a JSONB-backed LocalizedField and retain all the postgres goodness if one decides to drop into raw SQL.
If I understand correctly, all the recent stuff around indexes and uniqueness can be redone on top of JSONB, too.
The only downside I can think of is a slight performance hit when filtering on JSONB fields. However, I don't think this is a reasonable pattern anyway.
What do you think?
I am wondering why would composability be needed for localized fields?
One of the use cases that I have in mind:
- I use a JSONB field to save a semi-formatted long text (e.g. a blog post)
- modern Postgres allows to make queries into the JSONB and build indexes on it (e.g. for a full-text search)
- I want to make it localized
- as far as I know it's impossible to get an index over JSON in HStore.
Another use case is reporting over localized JSON fields. I like Metabase a lot, but it only allows SQL queries, so I can't query into json-as-text-in-HStore (again, as far as I know).
First of all. Sorry for not giving your issue (and PR) the attention it deserves. Things have been busy and I haven't gotten around to replying to all of it. I'll try to pay more attention.
This is an interesting idea and it would certainly bring some advantages. The performance hit worries me though. Performance was a major factor when deciding to develop this library rather than using any of the existing localisation libraries out there. All of them using nasty tricks or using foreign key relationships, which would require joining etc. HStore is however much simpler than JSONB, that's why I picked it when developing this.
I'd be open to supporting both. It wouldn't be that hard to for example add a type parameter to the fields to allow switching between HStore and JSONB. This would add support in a backwards compatible way. It wouldn't break existing code, yet allow people to pick JSONB if they want. It would also be nice to still take advantage of the performance HStore offers in most cases, but accept it in another, in the same code base.
I dont' envision breaking HStore support, but I would welcome support for JSONB, as long as it doesn't break anything.
FYI: A while ago I put in a lot of effort to move all the logic for unique indexes on HStore fields etc into a separate library: https://github.com/SectorLabs/django-postgres-extra
In case you'd want to add JSONB support, it would be nice to add it to that one first. After that, adding support to this package should be relatively easy. The architecture in django-postgres-extra allows for easily adding support for that (if correctly).