The Ideal Domain-Driven Design Aggregate Store?

Re:The Ideal Domain-Driven Design Aggregate Store? by skrebbel on Tuesday December 09, 2014 @07:24AM (#8722328)

Does anyone have real field experience with using Postgres as a JSON data store like this? Most notably, I'm curious about migrations and evolutionary database design.

With oldschool relational SQL, you'd write migration scripts that alter the database schema and also port the data.

It is my understanding that many people who use MongoDB and the likes just tend to keep old data as it is, and make sure that the code just supports older versions (like missing keys, etc). So you'd get code like

    record = db.get(...)
    if(!record.subtype) record.subtype = "defaultSubType"

Or maybe something smarter with a version number in each document.

I prefer to not write that code, but I also really like the idea of (ab)using Postgres JSON stores, with identically structured JSON for each row.

Did anyone ever write JSON data migrations with something like Postgres? Or Mongo? If so, how? PL/pgSQL? Load everything into backend memory and manipulate it and store it back? What if you want to split aggregates? (i.e. you have 1M "Person" JSON blobs and want to split it into 1M "Person" blobs and ≤1M "Address" blobs)

[ Parent | on HN ]

Re:The Ideal Domain-Driven Design Aggregate Store? by netghost on Tuesday December 09, 2014 @11:01AM (#8723456)

Just write ordinary migrations with updates and such. I think you should able to manipulate the JSON without too much bother. Here's the functions available for JSON: http://www.postgresql.org/docs/9.4/static/functions-json.htm...

Here's more about the JSON type in Postgres: http://www.postgresql.org/docs/9.4/static/datatype-json.html

There's also Postgres' hstore, which I believe now shares the same backing as JSON(B), but may have a different API.

[ Parent | on HN ]