@seantempesta yes, :tx-data of tx report queue entries gives you the raw datoms asserted/retracted in the transaction

Hi all, Im having problems with accent's in my querys with fulltext (ex: Pelé not found when search Pele). Its possible to use ASCIIFoldingFilter when search is fulltext? The api doc say "Fulltext search is constrained by several defaults (which cannot be altered)". Adding an ASCIIFoldingFilter to the Lucene Analyser is one of these constrains? ty

@lellis i think you’re out of luck; that Lucene is used for fulltext search is an implementation detail. the only api you get is the one in datalog.

@robert-stuttaford Yeah, i found some emails in our group where you clarify this! I m looking for an elasticsearch datomic integration for do these accent insensitive search. You know anything that is better? tks

somewhere inside Datomic Map transactions are converted to List form. is this conversion fn accessible?

how can i see how many datoms my database has

would this be accurate??? (count (vec (d/seek-datoms (db/_d) :avet )))

hey guys question. I have yet another ‘tree walk’ question lol. I have a tree structure, built around say a :ent/child ref attribute. Given an entity, I want to grab children to say any depth. I can do this with the pull api’s recursive specs. But in this case I'd really just want the ids/entities in a list as opposed to the nested maps i’ll get back from pull in this case. and I also need to potentially do some filtering on them. So say, all the :ent/child matches for ?e where :ent/foo equals bar as well. Is there any way to do this in datalog?

@eoliphant You are aware of this post I where I replied to your original question about tree walking a while ago? https://groups.google.com/d/msg/datomic/_YiBRnBkeOs/0Gd-6lJmDwAJ

ah crap you did didn’t you lol. I’ve been covering a lot of groud over the past few weeks. thanks again 😉

@eoliphant Your new scenario is different in its particulars but the approach is the same: use a recursive rule

yeah and actually rules where i’m a bit weak and focusing more at the moment so this is perfect

also notice that you need to know whether you intend to filter children during or after your recursive walk

it makes a difference

i.e., should the children of non-:ent/foo="bar" be included or not?

right, in my case at the moment it would be during

right

does the match failure of a node automatically exclude it’s children or not

to filter during I'm pretty sure you need to include the filter inside the rule

and i do have another scenario where it will need to be done ‘after'

right

that makes sense

to filter after is just another datalog clause appearing after the recursive rule

(children ?parent ?child)[?child :ent/foo "bar"]

exactly. the results of the tree walk rule just ‘fall’ into the subsequent clauses

ok gonna give this a whirl 😉

I wonder what's the story with fulltext predicate - is it possible to specify tokenizer? If something I want to search is not in English?

@asolovyov: No, fulltext indexing in Datomic is only supported with the default Lucene tokenizer/analyzer. If you have more specific fulltext search requirements, it is recommended to run your own Lucene/Solr/... for fulltext search.

@stuartsierra I see.. eh, too bad, I just grew tired of ElasticSearch (because of unpredictable performance and convoluted queries) and thought maybe I should look elsewhere 🙂

Datomic's fulltext is just Lucene under the hood, so the end result is not much different from running Lucene yourself.

well... I do faceted search on top of that, so either I'm doing that by hands, or I should use something which does it for me - and that's ES right now. But could be Datomic, which has a little bit more predictable performance when you're just filtering by field.

also consider algolia if you can use a saas

I know this has been asked before (apologies): how can I stop the [Datomic Metrics Reporter] DEBUG datomic.process-monitor messages in the repl?

@andyparsons You need to edit logback.xml and turn down the logging level. If its set to DEBUG it's likely this was changed in the past as I believe logback.xml defaults to INFO. " <logger name="datomic" level="warn" />"

ah yes @jaret that makes sense. thanks!