Release 1.9 alpha 3

[taoensso]

Release 1.9 alpha 3

[ptaoussanis]

Will look shortly, thanks!

[ptaoussanis]

Just a heads-up: please pause further development until I've integrated all current changes. Will try get these in asap.

[ricardojmendez]

Acknowledged. If I have to do any other changes, I'll do them on feature branches and leave them unmerged for now.

[ptaoussanis]

Okay, have updated [com.taoensso/faraday "1.9.0-SNAPSHOT"] - changelog is here. There's no other breaking changes on your end, yes?

Could I possibly ask you to rebase against the current dev branch and update your tests for e8fa44a and 07f1489?

Renamed these options to keep the types clearer / to avoid confusion. Don't mind if something's a little unclear at first (e.g. proj for projection) so long as it's consistent and unambiguous once you understand the meaning. In this way I feel proj-expr is less ambiguous than, say, projection - since there's a number of uses of "projection" in Faraday and in keeping the expr we keep it clear what type we have in mind here. Does that seem reasonable?

If you can confirm that everything else still seems to be working okay, then I'll cut an alpha3 release.

Appreciate all the time you've put in on this, it's been a huge help.

[ricardojmendez]

Wondering about the rebase you did: Not a fan of finishing feature branches with a recursive merge on dev?

There's no other breaking changes on your end, yes?

None planned right now.

Could I possibly ask you to rebase against the current dev branch and update your tests for e8fa44a and 07f1489?

Sure, will do early tomorrow.

Appreciate all the time you've put in on this, it's been a huge help.

Glad it could contribute!

[ptaoussanis]

Wondering about the rebase you did

Not a general rule, just keeping things organized since you had a lot of commits coming in.

None planned right now.

Sorry, I mean other breaking changes already in that I may have missed while compiling the changelog.

Cheers :-)

[ricardojmendez]

I've re-done the tests for those commits, but tests are now failing (in a variety of ways) after the change from commit 484ee3d for issue #63.

It's not only my tests either, the batch-write-item call on the first tests after ;;;; Basic API throws an exception as well.

(after-setup!
   #(far/batch-write-item *client-opts*
                          {ttable {:delete [{:id 0} {:id 1} {:id 2}]}}))

Fails with:

Exception in thread "Thread-0" java.lang.IllegalArgumentException: No implementation of method: :kv-reduce of protocol: #'clojure.core.protocols/IKVReduce found for class: clojure.lang.LazySeq
    at clojure.core$_cache_protocol_fn.invokeStatic(core_deftype.clj:568)
    at clojure.core.protocols$fn__6757$G__6752__6766.invoke(protocols.clj:174)
    at clojure.core$reduce_kv.invokeStatic(core.clj:6572)
    at clojure.core$reduce_kv.invoke(core.clj:6563)
    at  [...]

How do you want to handle this? It's not clear what *attr-multi-vs? is supposed to indicate, since there are no comments. All tests pass if it defaults to true. It doesn't seem to be an issue of simply passing it on the opts for batch-write-item, as the test above still barfs.

Should I just push the commits as the tests work when it defaults to true, and let you deal with the breaking chance?

Update: I'll be AFK for a while today, pushing the commits so you can take a look.

[ricardojmendez]

Regarding breaking changes: yes, one's missing. See commit 4e1bbbe - update-table used to always expect the throughput, which is now optional, and that parameter is instead a map of possible changes.

[ptaoussanis]

Thanks, will take a look at getting everything finished up today!

[ptaoussanis]

Updated [com.taoensso/faraday "1.9.0-SNAPSHOT"] - changelog is here.

Local tests passing on my end, but I'm not using DDB so please confirm? If you give me the go-ahead, will cut an alpha3.

[ricardojmendez]

Hmm, tests seem to get stuck against a local DynamoDB instance after

Reflection warning, expectations.clj:566:16 - reference to field ns can't be resolved.
Reflection warning, expectations.clj:566:28 - reference to field sym can't be resolved.

This is what happened when we got an exception and a promise didn't get delivered.

Eventually they do fail with an error where it seems like it's attempting to modify an index while an operation is in process, but I do see the index-status-watch calls on the test. Will do further review.

[ptaoussanis]

Anything special I need to do to reproduce that?

I'm just running ./run-tests local on my end and everything's passing. FYI current HEAD is 711a1fc.

[ptaoussanis]

Would also note that the current HEAD no longer uses promises anywhere for this reason. The promises were unnecessary so just switched them out for plain futures which'll rethrow errors on deref.

[ricardojmendez]

Nope, just booted a local instance I'm using for other tests and ran lein test. Using ./run-tests local the tests do seem to pass.

Nevermind. Restarted that instance and tests pass as expected.

[ricardojmendez]

Updated and tested against my own code, all good on that end as well. Thumbs up for release from me!

[ricardojmendez]

BTW, just noticed a typo on the changelog:

v1.7.1 / 2015 June 4

This is a non-breaking maintenance elease

Notice elease

[ptaoussanis]

Great, thanks - just pushed [com.taoensso/faraday "1.9.0-alpha3"] to Clojars