Skip to content
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

JSON values converted to strings with some NoSQL adapters #42

Open
LexLythius opened this issue Apr 3, 2015 · 1 comment
Open

JSON values converted to strings with some NoSQL adapters #42

LexLythius opened this issue Apr 3, 2015 · 1 comment

Comments

@LexLythius
Copy link

Columns of type JSON result in objects being written as strings with some adapters (redis in my case), e.g.:

{"foo": "bar"}

yields:

"{\"foo\":\"bar\"}"

The immediate cause is that AbstractClass._forDB method checks this.schema.adapter.name (which is not always set inside adapters) against a pre-defined list of NoSQL drivers, from which redis is absent.

@LexLythius
Copy link
Author

As an expedient my pull request #43 fixes the problem (n.b. in a data backwards-incompatible fashion).

However, I see a few problems with this approach:

  1. Abstract DB class has to know in advance of adapter implementations.
  2. NoSQL is really a vague umbrella term. The important thing here is whether a given adapter can handle JSON objects on its own or not.
  3. Adapters names are not enforced; however, data massaging logic depends on it.

I figure the best solution would be to have adapters extend from a common prototype having:
a. an "abstract" name method that by default throws an Exception and should be overriden in derivatives.
b. an implementation-specific method able to massage data fields as necessary prior to insertion, or
c. an implementation-specific method that tells whether the adapter can handle given data type on its own.

Whatever the implementation, the concept is letting the adapters handle data massaging on their own, or at least avoid forcing the higher level classes to know which adapters can handle which data types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant