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

Non-functional properties multiple "Append" => 1 element #124

Closed
cjslep opened this issue Oct 18, 2019 · 3 comments
Closed

Non-functional properties multiple "Append" => 1 element #124

cjslep opened this issue Oct 18, 2019 · 3 comments
Assignees
Labels
bug Something isn't working

Comments

@cjslep
Copy link
Member

cjslep commented Oct 18, 2019

Ben indicated to me that the "non-functional" (still a stupid name for "multiple-values") attachment property wasn't actually appending more than 1 value:
https://git.lubar.me/lubar-local/ravenvale/src/branch/master/fedi.go#L793

Must investigate more.

@cjslep cjslep added the bug Something isn't working label Oct 18, 2019
@cjslep cjslep self-assigned this Oct 18, 2019
@cjslep
Copy link
Member Author

cjslep commented Oct 19, 2019

809fd1f adds failing unit tests for this use case.

@cjslep
Copy link
Member Author

cjslep commented Oct 21, 2019

I finally had a sec to look at this. I identified root cause. If I don't ignore the error:

err := attachmentProp.AppendType(&testContextWrapper{firstObject})
if err != nil {
  panic(err)
}

I get the error:

illegal type to set on ActivityStreamsAttachment property: *streams.testContextWrapper

So it's because the testContextWrapper isn't implementing an expected interface, like vocab.ActivityStreamsObject.

The second object in the test is able to be set correctly.

@cjslep
Copy link
Member Author

cjslep commented Oct 22, 2019

There is a fix in 84ee361:

Change:

type testContextWrapper struct {
  vocab.Type
}

to:

type testContextWrapper struct {
  vocab.ActivityStreamsObject
}

Note that in this case, only serialization is supported. Go-fed cannot deserialize things into concrete types that haven't been explicitly code-generated for. For proper serialization and deserialization support, ontological types should have requests added to #121

@cjslep cjslep closed this as completed Oct 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant