Fork me on GitHub
Oliver George01:07:06

Hi @stuarthalloway I'm curious why the ion-event-example breaks the schema into keyed chunks and only migrates new chunks. Specifically:

Oliver George01:07:21

There would be less moving parts without the grouping. Perhaps there are performance considerations with loading the whole schema (even if 95% unchanged) each time. Can see it would be more managable working with a large edn schema file with chunks & would allow migration to report what schema chunks are being loaded...


hi @olivergeorge ! it is just sample code, I don't have any agenda about how people manage schemas and migrations

Oliver George21:07:29

Thanks for clarifying

Oliver George01:07:35

(I'd love to see other people's approaches to declaring and migrating schema too.)


I’m working this out for myself right now. I’m deploying parts of my app using the “component” lib where each component deploys it’s own schema on start. It could be a bit heavyweight inside an Ion but so far it’s ok. I’ll blog on this later if the pattern holds up as the app grows

👍 4

I’ve used conformity a good bit with on-prem, for schema mgmt. Coming from aeons of using flyway/liquibase/etc in the java/sql world it seemed a good fit. It needs some love to get it working with the client api, been thinking about tackling a pr. But yeah for now @olivergeorge, I’m just memoizing the load of the whole thing


I have a couple questions about the ion-config.edn stuff The :allow section lists what datomic is allowed to call. The ‘entry points’ if you will. In looking over the starter though, I don’t quite get how a function, that’s not a lambda would ever get executed directly, and need to be ‘allowed’. Are non-lambda funcs just there to take advantage of the namespace loading? If that’s the case maybe it’d be cleaner to have a separate more explicit tag? Also, the reference describes the ion function signatures. It appears that the transaction and query types are really just recommended conventions, while the lambda and web service types are describing the actual required function signature. Is this the case?


If I understand it correctly, you need to :allow transaction and query functions. They aren't lambdas but they need to be declared in case an external client called them through a query or transaction.

👍 4

ah lol. I’d jumped right into lambdas, etc and totally missed that we now have transaction funcs, etc via ions as well Was really missing the transaction funcs. We use them judiciously, but for some key functionality in for on-prem


hi, what’s the story for logging with ions? went poking around in the log for the lambda, then remembered that they’re just the glue. And the system or whatever log just looks like health stuff


I haven't messed around with logging too much, but I would try prepending something searchable like the current namespace and then searching the "datomic-<compute-stack>" log-stream for it.


You can use any logging tech you would use for EC2, but stay tuned, help is on the way.

👍 4

I’m fairly certain that ‘stdout’ logging isn’t showing up in the compute stack’s log stream. Ok @stuarthalloway will try using CWL or datadog or something directly


hey @stuarthalloway just an FYI, looks like the doc page has 2 copies of the same content


thanks, will investigate!


@stuarthalloway What version of jackson-core does Datomic Ions use? I found that my code was getting broken only in my deployment because of my dependency on cheshire and its transitive dependency on jackson-(core|dataformat-smile|dataformat-cbor) 2.9.0. Pinning them down to 2.8.11 seems to have fixed it.


Hi @U0LSQU69Z! We just did an update to help people with this problem:


I am guessing you are on an older release than that one.


Yes! Thank you!


are there any restrictions on outbound traffic for ions? I’ve looked over the net acl’s and sg’s but didn’t see anything obvious. Trying to shoot my logs over to loggly, but nothing is showing up