so "hypothetically" let's say there's a pretty tricky and crazy relational data model that exists in postgres, and I want the cheapest and potentially incorrect solution to migrating that data into datomic. i know "there be dragons", but this is mostly for the purpose of forming a proposal to the rest of my team

two other questions: we moved to postgres 9.4 for JSONB support. curious if any datomicistas have thoughts on how one might go about pitching a smooth transition away from that in order to get to Datomic

and second question: as far as im aware, the fulltext support is not really open in any way shape or form. we also take advantage of tsvector and tsquery in postgres. so a similar question to the above: thoughts? my understanding is that not enough of lucene is visible to be able to say they're capable of the same stuff

TL;DR help me out on selling it. I think we'd benefit greatly in some respects if we were able to query history, the log. ewald's reified transaction talk + sagas also looked pretty ripe

but having indexing on JSONB and the fancier fulltext makes me iffy on whether the tradeoffs are enough to justify switching

@devn id say the usual motivations for Jsonb are either schema flexibility or the need for raw storage. You get the first one out of the box with datomic; as for raw storage, you can always encode your attributes in json, nippy or fressian

@devn migrating a schema from sql to datomic is pretty straightforward I believe

@devn as for selling it, don't forget one of the biggest advantages of datomic is that the database is not remote. When you no longer have to think of your queries as an expedition it really changes your life

Took me some time to discover this, maybe it will help someone: https://gist.github.com/vvvvalvalval/5547d8b46414b955c88f

@val_waeselynck: totally reasonable on the jsonb front, though the fulltext sure would be nice

we're also leveraging hstore pretty heavily