FYI, beta10 (with the exception of onyx-datomic, i used the deployed SNAPSHOT on clojars since there were no code changes) works for my topos which were broken prior to beta8

Great!

0.10.0-beta10 is out

congrat!

if anyone has any pointers I'd appreciate it

@theblackbox i had this once, where my task runtime was trying to use a lifecycle resource that was created at compile-time

might be totally unrelated

I'm well flummoxed on it and all I can imagine (because I'm a dunce) is that there is some sort of "contract" on a batch-size?

but I'm literally pulling that out of thin air

that doesn’t sound like something that would cause a NPE — a range exception perhaps

can you paste some code ?

specifically, the code that allocates your lifecycles and the code that uses it

@theblackbox What’s at range.clj line 31? It looks like that’s the last line of your stack trace that’s NPEing?

yeah, that's what I don't understand... sorry was just trying to get the lifecycles

these get merged and are the only lifecycles I've got at the moment

The exception message is saying that there was an error in the prepare-batch lifecycle stage, not that your lifecycles are bad. I would try to go the last bit of the stracktrace and look at what’s happening in that file.

yeah that was my understanding

so if that is where the exception is thrown, I would have expected the failure to be on assignment by the doseq?

as in logging don't give no beef for nil, right?

@michaeldrogalis I appreciate the help by the way - no bother if you are busy 😉

@theblackbox I’d need to see a reproducer to help more - it’s hard to debug stack traces from afar when you don’t have the files. range.clj definitely isn’t in that trace by accident though, so I’d hunt around there.

yeah totally understand

thanks - I at least know I'm not wasting my time digging 😉

No prob 🙂

well... if I take out the timbre log line it works.....

I think I need to go back to the manual on this one. Thanks for the help.

@theblackbox: ((timbre/info "[MODIFY] : " key " - " value) (mc/find-and-modify db "documents" key {$inc value} {:upsert true}))

Is it possible to change the window settings at run time?

You’re invoking the result of info with the argument of find-and-modify

Pretty sure info returns nil. There’s your npe

@drewverlee No, the job needs to be restarted. Onyx jobs are immutable after submission.

Was 95% , sure of that

ahhh dang!

cheers for the eyes michaeldrogalis

Np

out of curiosity - is there anything that would help spot mistakes like that? paredit for instance?

I'm in the habit of using Cursive, but I've come at clojure very green and know for sure I'm not making the most of the tools available

I guess in this case it's just a matter of having more experienced eyes as it's pretty obvious what I was doing now you point it out.

there are some tools like eastwood and kibit that I used a bit when I was a beginner, but it’s kinda hard to find issues like that because of the semantics of the language.

tbh: with hindsight I'm a dumb ass because it isn't even "-bulk" as I decompose the queries into the doseq. I should be building the queries more appropriately for use with update and it'd be a damn sight nicer. Like I say, I'm still green 😉