Same as sticking with Clojure I guess? the alternatives are worse for what we do.

and using mysql with datomic is something you do only under duress. For us it was the only compatible hosted google storage option available

Ok I guess "the alternatives are worse for what we do." is a good of enough reason. Just find it weird that they never fixed this, since mysql is still listed as a supported storage

with no warning about this

the supported storage is "sql", and they happen to include some sql scripts for setting up the tables

in each of mysql, postgresql, and oracle dialects

I'm not sure that's the same as "mysql supported"

is included in the distribution package

so its ok to ship bad sql scripts?

I'd like it if they were better, but I don't feel like they're promising very much

Do you need the history/time features of datomic?

life is pain without them

it's really hard to go back

any mutable storage we use as a disposable one

Is that because you need high audit ability or somehting else?

we're in medicine so there's a baseline that's required, but datomic alone is not a full solution to that anyway

you need read logs too, and the datomic write log is too granular to make sense to an end user

but the difference for developers is incredible

it's like the difference between vcs vs non-vcs code

dbs are consistent snapshots even on small time scales, so lots of distributed system problems go away

if we make buggy writes to the db, we can find them and fix them

Yeah, I can see how it can also help a ton with debugging

we end up answering "how the heck did this happen" questions we never could have otherwise, or which would have been too much work

and having a graph-shaped db with extensible schema is a big plus too

much easier to model and change than table-shaped or document-shaped dbs

yes, those are all very handy and nice features of datomic, I guess my initial concern was about the sql script was more about the future of datomic on-premise

not as good for fast searches but because the db is so consistent and has a granular, incremental change queue it's easy to make derived views in other systems

oh, yeah, I don't know if on-premise has much of a future

that's the way the whole world is going for better or worse

"run this service yourself" is getting increasingly niche

heh true

I think it's just a Clojure thing generally though

what do you mean?

stuff in clojure's constellation tends to be well designed and "simple" (in the sense of decomposable pieces) but have terrible fit-and-finish

with experience you don't see it anymore

very true, mirrors my experience, get stuck too much in these "terrible fit-and-finish" details

Like "this is great" but then this little thing puts you off

like a bad sql script heh

going to try it with pg, thanks for the msyql warning

Regarding on-prem, I don’t see it going away anytime soon, if ever. It’s still their “flagship” product - Cloud is a more constrained version that is great if it happens to fit your particular requirements, but that only hits a small subset of use cases. To replace on-prem completely, they would first need to achieve feature parity in Cloud as it is missing some features that are critical requirements for a lot of use cases, like excision (pretty much anyone operating in the EU would need this capability). They would also need to extend Cloud to other platforms, like GCP and Azure, which would probably be a substantial effort. And even then, you would still have a non trivial number of customers that would demand deployment on their own infrastructure, either self hosted or on a private/hybrid cloud. Also look at the difference in licensing between the two - on-prem has got to be more profitable for Cognitect. I think Cloud was always meant to be a low friction way to bring new users to Datomic, and then up sell them to on-prem if/when their requirements exceed what Cloud can do. I doubt it was ever intended to replace on-prem completely.

I'm sure on-prem will continue to exist, but it looks to me like cloud is getting their energy and attention in a way on-prem no longer will. On-prem has actually lost rather than gained supported storage backends. Cloud is a much bigger market. I frequently hear people ask about migrating from on prem to cloud and never the other way around, even granted the feature disparity. And cloud is closely associated with datomic ions, which is a big feature advantage vs on-prem and will likely never have any on-prem equivalent because of how deeply it is wedded to aws and the datomic cloud system

I'm pretty sure clojure's tools.deps/deps.edn tooling was developed to further the goals of datomic ions; if true that means ions is even bending clojure roadmaps into its orbit

@U09R86PA4 are you using mysql for other stuff that you can't trivially switch to pg ?

no, we're only using it for datomic, but it would be a hassle

switching is never trivial

I though datomic backups made this easy, but I"m not experienced with it

backup-restore the db, figure out, set up and distribute new credentials, change all connection strings everywhere, rebuild and redeploy all images, etc

yeah, but moving the data is just one part

it's embedded in a running production system now. we could do it but without a clear tangible benefit it's just pointless busy-work

ah true

and like I said, most of the load is borne by memcached

@U09R86PA4 you may be right. Just as a counter argument, I see Ions a bit differently. Ions were needed to make Cloud feasible for non-trivial applications. For me at least, initially Cloud was just one of those “oh, neat” things - it wasn’t until Ions were available that I could really take it seriously. Without local querying, Datomic loses quite a bit of its power IMO. That’s the real purpose of Ions, to restore local querying, and the rest - like running your back end on Datomic’s infrastructure- is just gravy (and honestly, I can’t think of another way to make local querying work without going that route). So, that could explain why so much focus and resources were put into Ions, tool.deps, etc. - it was critical functionality needed to make Cloud a viable product. Even if the long term roadmap is away from on-prem, it will take some time. Given the pace of releases in the past, it will probably be at least a year before Cloud reaches feature parity with on-prem (unless Cognitect decides to double down and invest a lot more resources into Cloud). And more platforms will take time - AWS is the king now, but it’s hard to ignore the gains Microsoft have made in the last 2 years, to where Azure is on the verge of being a serious competitor (if not already). Point being, if the death of on-prem is imminent, we’re talking years before that happens.

well sure, they have to support their existing customers, but all the hot/new stuff is going to happen in cloud for sure

It means your transaction contains a tempid as value but does not create a new entity with the same tempid so there is nothing to point this attribute to.

when i see this it's usually because i forgot that some reference value should be more nested than i thought:

{:tx-data [
           ;wrong
           {:player/name  "Brian"
            :player/color :green}

           ;right
           {:player/name  "Brian"
            :player/color {:color/rgb :green}}
           ]}

Thank you for the replies guys - I really appreciate it. It turned out.... basically it was the wrong type. We were setting an id to another object as a string when it should have been a Long.

But... the error message was confusing

It should do some kind of "is this a valid ref format" check before hand. Also... I think I discovered a small bug/defect in datomic. When it dumped its stacktrace, for every method it dumped the full text of its API documentation.

Strings are valid ref formats. You can now use simple strings instead of temp ids. I don't think Datomic can return a better error here.

https://docs.datomic.com/on-prem/transactions.html#creating-temp-id