Clojurians Log v2

Can I use db.attr/preds with database functions ?

We seem to have hit a snag. We have on-prem, but we reach it with the client api. If we install a database function with a peer connection, and we (datomic.client.api) tx-range over this transaction it triggers an exception: Could not marshal response: Not supported: class clojure.lang.Delay. Similarly, if we datomic.client.api/pull the database functions ident, we get the same marshal exception, whereas datomic.api/pull (with a peer conn) returns the fn without a hich. Is this a known bug?

As I understand queries with fulltext search require :db/fulltext in the schema for that particular attribute to be true. Is it possible to alter the schema of an existing database to allow fullext search? When I transact [[:db/add :my-thingy/name :db/fulltext true]] I get an error:

:db.error/invalid-alter-attribute Error: {:db/error :db.error/unsupported-alter-schema, ...

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.

I've tried really hard to find an online example of using create-database with a sql/postgres backend. I spent the entire day yesterday trying to get this to work. I'm using datomic-pro. I can create a db using the "dataomic:free" image and my own datomic pro with "datomic:mem" but no luck with a real storage backend. I can't use cloud and don't want to be forced in to dynamodb or cassandra at this point. I'm trying to sell this stack to a new (non-clojure) group so I want to lower the number of new technologies at POC time. Any examples out there?

Hi @lennart.buit , 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:support@cognitect.com|support@cognitect.com>

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

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

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 @astro, 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?

Can do!

I watched more. Excellent resource. Thanks @lanejo01

:db/doc is a way to annotate an attribute. can i annotate an assertion?

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

Hey @michael740, 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 @lanejo01

Great 👍 Always nice to hear from you @michael740!

likewise!

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