jsonb_accessor icon indicating copy to clipboard operation
jsonb_accessor copied to clipboard

Feature suggestion: supporting multiple databases

Open abuisman opened this issue 2 years ago • 6 comments

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.

abuisman avatar Aug 01 '22 16:08 abuisman

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 avatar Aug 05 '22 09:08 haffla

@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?

abuisman avatar Aug 05 '22 14:08 abuisman

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 avatar Aug 06 '22 18:08 haffla

@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.

abuisman avatar Aug 08 '22 19:08 abuisman

Good point. Let's do it your way.

Yes json and jsonb as cast type are interchangeable basically.

haffla avatar Aug 09 '22 09:08 haffla

Nice! Glad we hashed this out. I will have a go at it and report back, hopefully with a PR.

abuisman avatar Aug 09 '22 14:08 abuisman

Closing for inactivity.

haffla avatar Dec 06 '23 17:12 haffla