Fork me on GitHub

Is it possible to use a partition in the same transaction the partition is created in?


@kenny no, you must create the partition prior to using the partition


@jaret thought so. Thanks.

Ethan Miller09:05:25

Anyone know what's a good, cheaper, ec2 instance that works for a AWS deployed datomic transactor? The default is c3.large which is a bit expensive for my little project.

Ethan Miller09:05:12

I looked around and it sound as though some ec2 instances won't work, but I couldn't quite determine what the requirements are.


ezmiller77: I think it's about access to the local filesystem


@ezmiller77 It's possible to run a Transactor on an EC2 micro, though only for tiny workloads. A 'small' instance works for light load, you just have to set the heap and cache sizes correctly on the transactor.

Ethan Miller05:05:50

stuartsierra: Thanks for the response. My little project just serves results to a single blog (my own), which is not exactly getting hit by a lot of requests 😉. I suppose that qualifies as a tiny workload, no?


hey @marshall + @jaret – were you able to find out any more info on the issue where tx-range can potentially produce a clojure.lang.Delay? referring to: i'm seeing this consistently using onyx-datomic on a fresh datomic-pro 0.9.5561 db with schema installed and about 500 generated entities.


hey @all, I work at Indaba Media, and we're customers of Datomic.


we just had an issue where we forgot to set some attributes to be fulltext indexed, and apparently you can't alter fulltext-indexing status through a migration.


So our current plan is to rename the ident for that attribute to something else. then reinstall that ident with fulltext-indexing set. Then port the data we currently have over from the old renamed ident to this new one.


a couple questions: 1. is this a decent strategy?


yedi: why not simply create a new attribute, migrate the data over to it, and change the client code to use that one? Seems easier operationally


@U06GS6P1N we're only in alpha currently and don't have much data for this attribute. So i'm thinking preserving the name is worth it as long as there's no major operational issues with this method


well I'm not sure what you suggest is feasible without an interruption of service


and a breaking change in your database e.g you won't be able to go back to previous versions of the code.


and 2. we have other fields that we might want to make fulltext indexed, but we're not currently sure about them yet. Since it isn't trivial to make them fulltext-indexed down the line, we're considering just making them indexed from the get go. What are the performance trade-offs for having a bunch of fulltext-indexed attributes?