Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

alia/execute fails silently with extraneous keys in the connection map passed to alia/cluster used in alia/connection #96

Closed
Reefersleep opened this issue Oct 25, 2018 · 7 comments

Comments

@Reefersleep
Copy link

Reefersleep commented Oct 25, 2018

Hello mpenet

I'm in doubt about whether this is a known issue or even accepted, known behavior.

I've experienced problems with the connection generated by alia/connection using a cluster generated by alia/clustercalled with a map that includes keys in addition to the ones generated in the documentation. Nothing seems to go wrong at connection time, but at alia/execute time, exceptions occur. (Sorry, don't recall exactly which, and the problem is fixed now and the project is moving on).

It would have been nice for cluster or connection to validate the map passed in and throw upon extraneous keys, rather than failing silently and causing errors later on - this made it much harder to figure out the error.

Kind regards
Reefersleep

@mpenet
Copy link
Owner

mpenet commented Oct 25, 2018

Hi,

I can make it so that extra unknown keys will not cause errors, but I will not do strict validation of the keys. You can already use the specs provided if you want to make sure the correct keys hold the correct values but it will not check extra keys by itself (some spec based libraries can do that if you want to do so).

@mpenet
Copy link
Owner

mpenet commented Oct 25, 2018

By the way you can patch this at runtime with the following:

(defmethod qbits.alia.cluster-options/set-cluster-option! :default
  ;; let unknown keys flow, or throw 
  [k builder x] 
  ;;  return `builder` to let it flow
  ;;  or throw: 
    (throw (ex-info "Unknown config key" {:type ::unknown-key :key k :value x}))
) 

@mpenet mpenet closed this as completed Oct 25, 2018
@Reefersleep
Copy link
Author

Cheers Max. Being robust towards extra keys (I guess by ignoring them) accomplishes the same goal in my eyes, and is in the spirit of Clojure in general :) As I see it, at least.

And thanks for the tip!

alia and hayt, are great. so thanks a lot for them! :D

@mpenet
Copy link
Owner

mpenet commented Oct 25, 2018

I agree.
I commited a change that let extra keys flow earlier. I ll release a new version tomorrow with the change.

Thanks for the report!

@mpenet
Copy link
Owner

mpenet commented Oct 26, 2018

available on clojars as 4.3.0 (why the jump from 4.0.2 to 4.3.0 you might ask? "Lack of coffee" before updating it would be my answer).

@Reefersleep
Copy link
Author

Awesome!

Are you also actively developing hayt? I think I've been missing some CQL syntax equivalents a couple of times. Should either create issues or PRs once I remember what they were, if it's an active project?

@mpenet
Copy link
Owner

mpenet commented Nov 5, 2018

It's active, but I am not using cassandra as much as I used to right now so it's lacking some love. I would very much welcome prs to keep it up to date, it's fairly easy to extend with the new stuff I expect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants