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

seq'ing a PersistentProtocolBufferMap yields only two of the four fields #39

Closed
jmibanez opened this issue Jan 4, 2013 · 2 comments
Closed

Comments

@jmibanez
Copy link

jmibanez commented Jan 4, 2013

Using the latest release of clojure-protobuf, and this particular .proto definition:

message Key {
  required bytes salt = 1;
  required bytes iv = 2;
  required bytes encryptedKey = 3;
  required bytes verifyingKey = 4;
}

When ever I try loading from a file via protobuf-load-stream or via protobuf-load, the returned protobuf object does not yield the encryptedKey and verifyingKey keys, and its str representation doesn't have those keys either, e.g.:

protobuf-raw-seq
-> {:salt #<ByteString com.google.protobuf.ByteString@ca222b04>, :iv #<ByteString com.google.protobuf.ByteString@ae9053d8>}

(:encryptedKey protobuf-raw-seq)
-> #<ByteString com.google.protobuf.ByteString@e2fd05ec>

(take 4 (seq protobuf-raw-seq))
-> ([:salt #<ByteString com.google.protobuf.ByteString@ca222b04>] [:iv #<ByteString com.google.protobuf.ByteString@ae9053d8>])

A function that I've written to unpack ByteStrings into byte arrays and translate the protobuf object into a Clojure map depends on being able to seq into the PersistentProtocolBufferMap without losing keys.

This is on Clojure 1.4.0

I can provide a minimal test case. I am not sure whether this is a bug in clojure-protobuf or protobuf itself, but doing (.. protobuf-raw-master-rec def type getFields) does yield the missing fields.

@eRaz0rHead
Copy link

I believe this is the same error I discovered -- If I am correct, this is because of the mixedCase in the missing keys.
If you were to check your schema you'd find that the keys are :encryptedkey and not :encryptedKey.

However, the actual value is stored with the camelCase key, and so the toString() method is calling .get( ) vs .get () , which returns null and so it's left out of the output

@amalloy
Copy link
Contributor

amalloy commented Apr 22, 2013

Yes, this is a duplicate of #45: the default naming strategy doesn't work for mixedCase keys.

@amalloy amalloy closed this as completed Apr 22, 2013
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

3 participants