jsonb_accessor
jsonb_accessor copied to clipboard
Feature suggestion: supporting multiple databases
I recently discovered this gem and I think it is great as a concept, but, I want to avoid PostgreSQL for my project as long as possible.
I included the jsonb_accessor anyway and the basic accessor functionality works, but it adds the pg
gem to the bundle because it is a dependency.
So I extracted the Macro and Helpers and renamed the module to json_accessor
and I now have that part working on SQLite.
That made me think it might be an idea to split parts of the gem into two gems or some other structure so that pg
isn't a requirement anymore and that people might even write their own query adapters or something like that. Sort of like how ActiveRecord supports multiple databases. It might even be as 'simple' as not having pg
as dependency anymore. You'd then choose which query adapter to require by looking at the presence of sqlite
, pg
, etc. If there is more than one you choose pg
over sqlite
and make it a config option or basing it on which connection the model is using or something. I am unsure of what is possible here, but it is solvable.
I am willing to do the work or participate, but I am unsure about the architecture or if you guys are even interested at all. Postgres is a de facto choice for most production environments and SQLite is more in the hobby/development tier, but it might help in adoption to have flexibility.
I read in the README that there are some advantages that jsonb and postgres have over I guess hstore and I am not sure which they are and whether some parts of the gem are simply not doable without jsonb or postgres.
I am interested in people's thoughts.
Sounds extremely interesting. I think it would be possible to remove the pg
dependency since users of this gem would have that installed anyway. I am looking forward to a PR. I am a bit concerned about changing the name of the gem though. But yea jsonb_accessor
wouldn't make much sense anymore if you could use it with sqlite
.
@haffla good to hear.
With regards to this part of my message:
I read in the README that there are some advantages that jsonb and postgres have over I guess hstore and I am not sure which they are and whether some parts of the gem are simply not doable without jsonb or postgres.
Can you think of anything that might be Postgres-only? What is the thing in the readme about “collections” that is not possible in hstore but is possible in jsonb?
Hi @abuisman,
I think most of the scopes that this gem is adding will not work anymore. Another reason to always use jsonb
over json
in Postgres. json
only has a limited set of operators.
I still think it could be a great idea to extract everything that doesn't have to do with scopes into a separate gem.
@haffla I see what you mean and I too think it would be a shame to have to rename the gem.
We could opt for aliasing JsonAccessor
as JsonbAccessor
and add a deprecation warning.
We could then optionally load the query additions that do work for each type of database. Then there won't have to be 2 gems, which makes it easier to maintain the code.
Another question:
When looking at this line: https://github.com/madeintandem/jsonb_accessor/blob/master/lib/jsonb_accessor/macro.rb#L60
It has attribute jsonb_attribute, :jsonb...
. Is it crucial for it to pass :jsonb
or :json
depending on the column type in the database. Come to think of it: the feature works on sqlite without me changing this line, so it seems that :jsonb
and :json
are interchangeable.
Sorry for all these questions. I just want to get on the same page in the approach before I start coding so that the path forward can be as smooth as possible.
Good point. Let's do it your way.
Yes json
and jsonb
as cast type are interchangeable basically.
Nice! Glad we hashed this out. I will have a go at it and report back, hopefully with a PR.
Closing for inactivity.