(q db '{:find [name (pull workout [*])]
                                          :in    [[search user]]
                                          :where [[workout :workout/name name]
                                                  [(clojure.string/includes? name search)]]
                                          :order-by [[name]]}
                                     [(string/lower-case (or (:search params) "")) (:uid session)])

this is what im working with

i see the string functions but adding (lower name) throws an error

Lucene index is best for FTS, calling the includes function needs to consider every doc that has the name attr.

You can call clojure fn to do the lowering in query as well [(clojure.string/lower-case name) lower-name] and use that

right that makes sense, time to learn about indexing 😄

you can use < and > etc on strings as well, but that obviously works from the start of the string only

and is case sensitive

yes, it'll see the effect of prior operations within the transaction

Right, but can I actually get e.g. the list of put ops and documents that come before it?

ah, I see - not as operations, no, not a use case we'd considered :thinking_face:

I'm imagining a final tx fn that would determine what else might need to be done, based on what was transacted before it.

I could do this before submitting the tx, but then I might need to think about staleness.

right, yep

would it also be an option to widen the scope of your tx-fn?

you could potentially also put a separate event-like document earlier in your tx that you then query for in the tx-fn?

Hm, I'll consider that. > would it also be an option to widen the scope of your tx-fn? How do you mean? (If the msg below wasn't a continuation of that thought :))

as in, make the tx-fn your whole transaction - the prior operations, and the part that needs to react to them?

Aaah, yes, that could work 🙂

although maybe that wouldn't work if you needed to query the results of the earlier operations - you only get chance to mutate the DB with the return value of the tx-fn

but you could perhaps query enough to see what those operations would do (i.e. it'd be like doing it at submit but without the staleness issue)

> although maybe that wouldn't work if you needed to query the results of the earlier operations That is a good point. Would be more convenient to be able to do that, but should be workaround-able 🙂 Thanks for the quick reply, James. Cheers!

np, good luck 🙏

I don't think so? You should have enough information to generate a new transaction such that the data in the db after it will be as if it was rolled back. In other words, you would 'revert' all intermediate transactions.

Hey @U05F70RT9RQ I'm curious, is this just a dev / testing thing? Or do you have some production use case for that?

It's about migrating, and then rolling back if something goes wrong. What would be the best practice?

How do you define/measure "if something goes wrong"? XT's transactions are ideally usable for this, although I appreciate the atomicity may not be appropriate, especially if you have a LOT of data and need to avoid stalling concurrent transactions. How much data are you likely migrating? Roughly what size are the smallest boundaries of atomicity you could use? Is there a concurrent workload (i.e. it's a 'live' migration)? In the worst case I think you should be able to build up some userspace 'transaction' metadata that re-creates the kind of atomicity you are looking for.

...or you can join direct if that's preferable: https://meet.google.com/bcu-sqkw-ckf

great to meet & chat just now @U0CKDV6DB, @UGNMGFJG3 - whilst I'm no expert on statecharts or ClojureDart (currently!) I hope the tips on Lucene and transaction functions tests will be of use. Always feel free to ping me if you ever want more tips :)

Thank you @U899JBRPF

thanks! it was nice to meet you both. ClojureDart does look intriguing and I love the history lesson on datalog

Sorry, I was unavailable for this meeting time

Just FYI @U899JBRPF. I implemented a simple state machine in 2 lines! Thanks for getting me out of my head there.

@U899JBRPF did this happen to get saved anywhere? I was away and didn’t get to join.

unfortunately not this time - sorry @U050N4M9Z - but I will run another session on Wednesday and try to give everyone some more notice...and get into the habit of recording again 🙂

no worries! I’ll just have to wrestle with it myself the old-fashioned way. 🙂

well I would be happy to chat in the meantime or start a new thread here - no need to punish yourself(!