Fork me on GitHub

Is there a recommended practice for the scenario where multiple developers want to iterate (deploy code multiple times a day using :uname for example) on one datomic cloud stack? We're concerned with deploys overwriting each other, resulting in in-development functions being removed by whoever deployed last because their code doesn't have the in-dev code of someone else. One strategy we're considering is to all work on one git branch and always pull and push before deploying, but it would be great if there is a strategy that doesn't involve coordination.


we are doing development locally with http-kit instead of pushing ions. Each developer has their own database, named "$USER-dev" they can freely play around in


that doesn't work for tx functions


yep, we are doing similar with jetty. I'm wondering specifically about deploys. Is the only solution one query group/stack per developer?


not an expert in that, but the solo topology is so cheap you could easily have one for each developer


Currently attempting to upgrade to com.datomic/ion-dev "0.9.240" from "0.9.231" and seeing

Execution error (IllegalArgumentException) at datomic.ion.cast.impl/fn$G (impl.clj:14).
No implementation of method: :-event of protocol: #'datomic.ion.cast.impl/Cast found for class: nil


This is during a normal cast/event call. The only thing I've changed is updated my deps. Same issue @U6Y72LQ4A reported over the weekend. Anyone else seeing this issue?


The immediate issue is whether I need to update ion-dev to use the analytics features released in 512-8806.


It looks like the issue is tied to the com.datomic/ion "0.9.35" release. If I leave ion at 0.9.34, it's fine.


In my setup: com.datomic/ion "0.9.35" + com.datomic/ion-dev "0.9.234" doesn't work. com.datomic/ion "0.9.34" + com.datomic/ion-dev "0.9.240" does.


Agree on this downgrade solving my problem as well


per @U051V5LLP, looks like calling (datomic.ion.cast/initialize-redirect :stdout) (or likely another redirect option) prior to making any cast is a viable workaround until this gets fixed.


is this happening when running the code locally?


Yes. ion-dev is only used locally.


I found that this worked to get rid of those errors locally: (datomic.ion.cast/initialize-redirect :stdout) - invoke it early in your code before any calls to cast


That's interesting. I see that works here as well. That looks like a regression. This wasn't a requirement previously.


@U05120CBV What would be your preferred method of tracking this issue? Should I open a support ticket?


Done! Thanks!


I'm currently seeing some strange behavior. It seems like my code is not being updated with my deploy. No matter what I deploy the same response keeps getting returned. At one point I deployed a function that returned some json (ex: {showGrid: true}), and even if I go in and hard code what that function should return (now just some text that says "test") it still returns that same json as before. There haven't been any deploy failures. Anyone have any ideas?


Does it pass through a caching layer? CloudFront?


no. and in fact invoking the function directly in the terminal seems to return the old json as well.

Ian Fernandez19:11:18

People, I want to store a field with a java.time.ZonedDateTime into Datomic, some recommendations?


store in a tuple?


> A ZonedDateTime holds state equivalent to three separate objects, a LocalDateTime, a ZoneId and the resolved ZoneOffset. The offset and local date-time are used to define an instant when necessary. The zone ID is used to obtain the rules for how and when the offset changes. The offset cannot be freely set, as the zone controls which offsets are valid.


(from javadoc)


maybe encode the ymd as one long, hms as another, another long for offset, and a string for zoneid


if you want to ensure temporal sort order, perhaps the first element in the tuple can be the instant (java util date, or just a long of ms since the epoc) that the zoned-date-time would convert to


this guy datomics

metal 4
Ian Fernandez19:11:49

make another field with the Zone?


update on the above issue, when we change the namespace of the code we are deploying, we then see the code update, but if we push and deploy the original namespace with different code, we never see updates, we see the old code running and returning that same old json object. Anyone know why this may be?


How do I move an Ion from a staging to a production environment when the :app-name has to be defined in the ion-config.edn but needs to change across environments?


Q: is there any kind of shutdown hook available when deploying a new Ion version? I want to call the component/stop fn in my servers so that resources are properly cleaned up