IrenejMarc / dpq

Simple but powerful PostgreSQL library inspired by higher-level languages.
MIT License
21 stars 9 forks source link

Support for JSON Fields #17

Open ghost opened 7 years ago

ghost commented 7 years ago

I've tried using JSONValue in a struct, but I get

/root/.dub/packages/dpq-0.8.8/dpq/source/dpq/attributes.d(577,26): Deprecation: std.json.JSONValue.assign(T)(T arg) is not visible from module dpq.attributes /root/.dub/packages/dpq-0.8.8/dpq/source/dpq/attributes.d(577,26): Deprecation: std.json.JSONValue.assignRef(T)(ref T arg) if (isStaticArray!T) is not visible from module dpq.attributes

Searching this git repo also doesn't bring up anything other than a JSON constant.

Is there support for json fields (currently don't care about jsonb) and if so how would I go about that?

Thanks

IrenejMarc commented 7 years ago

There’s currently no JSON support. I’ll put it on my todo list.

ghost commented 7 years ago

Awesome! Thanks for looking into that. I guess it's just text strings 'till then.

Thanks again

IrenejMarc commented 7 years ago

It might be possible to use a string field in D and specify the JSON type manually for PostgreSQL, but I'm not sure if it will get rejected because of the wrong OID. Just an idea.

ghost commented 7 years ago

Unfortunately I don't know that much about how Postgres would/should handle that. I've been using Postgres' TEXT type and string in Dlang. So it's basically a blob hack equiv in MySQL. Works well enough for now.

ghost commented 7 years ago

As I was coding today I had an idea.

Lots of structs will end up looking like so:

struct User { UserSettings settings; // a json field in postgres ... }

Now, that would cause a type error or be assumed a FK/relation, but what if there was this:

struct User { JSON!UserSettings settings; // a json field in postgres ... }

Not sure if the naming would conflict with other packages but that's the idea. Then that struct is converted to a json for postgres.

IrenejMarc commented 7 years ago

JSON deserialisation in that case might cause more work than good. Since composite types are already supported, working on databases created with dpq is easier without that, and I think JSON support could just be implemented with a JSON serialiser and actual Phobos JSON fields in the structs/classes.