I’d like to deploy the same ion config to N different Datomic Cloud systems and use the same config locally with dev-local. Datomic only allows the ion-config.edn to be specified as a static edn file on the classpath. Right now we have to dynamically generate that file for each datomic system at deploy time. It feels quite hacky though. I’d really like a single “master” config where I can customize the :app-name at deployment time. How are folks handling this now? Is there some undocumented way to do this now? If not, this would be a very helpful feature to add.
1 Like
I have the same problem with dev and prod. I was going to write the same code you already have. I don’t know of another way to do this.
After implementing a way to customize the app-name I finally realized the proper way to do it is to leave the app-name the same and set it in the query groups that are deployed.
When you deploy a query group, set the SystemName to the name of the Datomic Storage stack and set the ApplicationName to the app-name. By default it is set the SystemName.
To keep data isolated, we run separate topologies for each stage. I think what you described @m0smithtb only works with a single topology.
In the planning documentation there is the scenario of isolated data, with multiple topologies/systems. It still mentions there, that the same rule applies - use the same application name, even across multiple systems. On deployment, you specify compute target name, which includes the system name as well. It has taken me a while to figure this out, and have finally ran across this section of the documentation today.
Geez, okay I think I have a better grasp on what’s going on now. The :app-name is a generic name for a bundle of code – it is entirely independent from the Datomic system name. When you deploy a Datomic compute or query topology, you specify the code bundle (:app-name) you want. If you don’t specify the :app-name, the default is the Datomic system name. There can only be one code bundle deployed to a compute/query topology at a time.
So it sounds like the solution for a “dynamic” :app-name is to actually use a static application name and specify that static application name when deploying your compute/query group.
Does this sound inline with your findings?
1 Like
Yes @kenny - this is my understanding now as well. :app-name is static and unique to a code repo or project (thus being set in a file in that repo), for me, it makes sense just to use the repo name. The target compute group should basically always be specified in whatever deployment scripts or process is running the “deploy” command/fn. And yes, there can only be one application (or ion) running in a compute group at a time, which makes sense, because of the configuration needed to expose certain functions.
I think the biggest reason for my (and possibly other’s) confusion, was that the tutorials and many sample repos out there, use :app-name and “system name” interchangeably, and if you don’t specify an app name (during creation), the default is to match it with the system name. This makes sense, to keep it easy to play with datomic, and get a solo system + ions running quickly.
I haven’t discovered these things yet, because up until now, I’ve just been developing my application, and have only needed a solo topology (the same one I first created). I’ve only just recently started planning my production system, and dev/stage policies. That planning documentation is very useful, but, now we have to figure out how easy it is to change the application name on existing compute stacks (if possible at all).
1 Like