Skip to content

Conversation

akdor1154
Copy link

Hey, I'm hitting the same thing as #2 (in exactly the same scenario):

  • I'm trying to create a GetJobs response (which has N Job attr groups, one for each Job),
  • but goipp's model of one-group-per-tag-type does not allow me to construct messages with more than 1 Job attribute group.

Here are my hacky changes that allow me to represent such messages: it's probably not mergeable as-is but I don't know enough about your other use-cases to try anything more substantial. If you were open to going down this path I'd be happy to put the work in for a more useable refactor.

Thanks for providing this in any case!

Jarrad

alexpevzner added a commit that referenced this pull request Nov 26, 2023
This change adds an ability to represent messages with repeated
groups of attributes with the same group tag. The most noticeable
use case is the Get-Jobs response which uses multiple Job groups,
one per returned job. See RFC 8011, 4.2.6.2. for more details.

With respect to backward compatibility, the following
behavior is implemented here:
  1. (*Message).Decode() fills both Groups and named per-group
     fields (i.e., Operation, Job etc)
  2. (*Message).Encode() and (*Message) Print, if Groups != nil,
     uses Groups and ignores  named per-group fields. Otherwise,
     named fields are used as in 1.0.0
  3. (*Message) Equal(), for each message uses Groups if
     it is not nil or named per-group fields otherwise.
     In another words, Equal() compares messages as if
     they were encoded
@alexpevzner
Copy link
Member

Hi @akdor1154,

now I understand what do you need. Please, review my implementation. It attempts not only to add the requested functionality, but to preserve backward compatibility with 1.0.0 as well.

@alexpevzner
Copy link
Member

Ping...

@akdor1154
Copy link
Author

thanks + sorry for my slow response!

I'm using your new commit and it works well enough. It's a small footgun for people like me who are constructing messages from scratch, because we need to be careful to either always set with a []Groups, OR always use the single e.g. .Operation accessors. However this is not insurmountable, and I can't think of any better way to change this without breaking back-compat :)

thanks again!

@alexpevzner alexpevzner closed this Dec 3, 2023
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

Successfully merging this pull request may close these issues.

2 participants