Hi @UDF11HLKC , could you file a support ticket and provide a stacktrace ( if there is one?)

Best thing you could do would be creating a secret gist, showing a minimal repro, and then send it to <mailto:[email protected]|[email protected]>

Can do!

Done, also, googling ‘datomic marshal error’ leads to a lot of comments by marshall about errors but not particularly about marshalling errors

Not sure I can do much about that one haha

You can't alter :db/fulltext , see: https://docs.datomic.com/on-prem/schema/schema-change.html#schema-alteration

You can rename the old attribute and create a new attribute (with db/fulltext). Here's an example: https://gist.github.com/ccfontes/3f566db393da14742a9a No experience with that approach though.

Unless this is a throwaway db that you know will never get big, I highly advise never using fulltext

it’s “easy” but it gives you very little power, and the lucene index has some catastrophic misbehavior. and as your application and db grows and maybe you move off to elasticsearch or something, there’s no way to easily get rid of this index

This may interest you and your team. Appears to use postgres https://youtu.be/QrSnTIHotZE

thanks, I give that a run-thru tonight. From a quick look, I think I was using datomic.client.api . Is it correct that only datomic.api and not datomic.client.api is required?

I'm not sure how best to answer that question @U120SKKNK, but if you're still stuck after running through that project tonight (BTW, the source is linked in the video descriptioin) reach out and we can figure out what's going on, sound good?

I watched more. Excellent resource. Thanks @U0CJ19XAM

Answering my question above re on-prem and create-database https://docs.datomic.com/client-api/datomic.client.api.html#var-create-database > > NOTE: create-database is not available with peer-server. > Use a Datomic Peer to create databases with Datomic On-Prem.

https://docs.datomic.com/cloud/transactions/transaction-processing.html#reified-transactions

Hey @U7EFFJG73, any reason you don't want to make your own attribute like the example you referenced?

Joe, no, I'm not opposed to creating new attributes

I think I'm not understanding your question...

I'm about to un-deprecate at attribute of ours and I'd like to include some comments about why - specifically, why we're changing our mind about the deprecation. :db/doc doesn't seem appropriate, since it's per attribute (i think).

including the comments against the transaction entity would work, too.

i'm just curious whether i could go even more fine grained and include a comment against a specific assertion within a transaction. that was my original instinct, before i knew about the per-transaction annotations.

am i making any sense?

I would attach either your own attribute or db/doc to the transaction entity if I was in your case. I think I understand the question. It's about documenting a change about 1 of n assertions within a transaction. Specifically, can you reify and individual assertion within a transaction of many assertions, right?

yep! and per-tx is perfect. sounds like assertions are not reified in the same way, which is fine.

Great, does this resolve things then?

yep, thanks @U0CJ19XAM

Great 👍 Always nice to hear from you @U7EFFJG73!

likewise!