Support Implied Keys

[iguessthislldo]

• Support Implied Keys:
  • If a nested struct has no specified keys and a field of the nested struct type is marked with @key, all the fields in the nested struct are implied to be marked with @key.
• opendds_idl will now error if the set IDL version is less than 4.
• Added topic annotation migration guide and updated deprecation warning and news file to point to it.

[iguessthislldo]

Another question: do implied keys apply to unions? If we're being consistent I think these rules should apply to union discriminators as well:

If a union field or array field in a struct is marked as a key or implied to be a key, then the discriminator is assumed to be the key unless marked with @key(FALSE).

[iguessthislldo]

I wonder if the Github user key has blocked me by now.

[iguessthislldo]

Another thought following my previous ones: If a user has marked a field in a struct of another type (union or struct) and all the possible keys have been marked with @key(FALSE), what does that mean? Is it an error or a possible chance to warn the user? Right now I think it would error with structs, which is the behavior before this PR.

[mitza-oci]

I wonder if the Github user key has blocked me by now.

Right... I'm trying to use @key formatting but I may forget sometimes.

[mitza-oci]

Another question: do implied keys apply to unions? If we're being consistent I think these rules should apply to union discriminators as well:

If a union field or array field in a struct is marked as a key or implied to be a key, then the discriminator is assumed to be the key unless marked with @key(FALSE).

I could see it going either way. The other argument would be that the semantics of @key in the outer struct seem to be saying "use this whole thing as a key," and that doesn't apply to the union example.

[iguessthislldo]

So I'm kinda confused. I changed the PR Jenkins configure step like 2 days ago to use --ace-github-latest, because it couldn't compile opendds_idl, but it's still acting like it doesn't have ACE/TAO #967 and giving the same error...

[iguessthislldo]

I could see it going either way. The other argument would be that the semantics of @key in the outer struct seem to be saying "use this whole thing as a key," and that doesn't apply to the union example.

I wasn't thinking of it applying it to a struct necessarily, I was thinking of applying it directly to the union field like so:

union UnionType switch (int) {
// ...
};

@topic
struct StructType {
  @key UnionType union_value;
};

Although I think it also apply indirectly as well if the union is implied to be a key:

union UnionType switch (int) {
// ...
};

struct InnerStructType {
  UnionType union_value;
};

@topic
struct OuterStructType {
  @key InnerStructType inner_struct_value;
};

[mitza-oci]

I could see it going either way. The other argument would be that the semantics of @key in the outer struct seem to be saying "use this whole thing as a key," and that doesn't apply to the union example.

I wasn't thinking of it applying it to a struct necessarily, I was thinking of applying it directly to the union field like so:

union UnionType switch (int) {
// ...
};

@topic
struct StructType {
  @key UnionType union_value;
};

This is exactly the one I was referring to. Does it make sense to say that "union_value is the key of StructType"? It's not really, only the discriminator can be a key so the union value as a whole isn't.

[iguessthislldo]

This is exactly the one I was referring to. Does it make sense to say that "union_value is the key of StructType"? It's not really, only the discriminator can be a key so the union value as a whole isn't.

Yes, of course you can't use the whole union value, but it's always possible use the discriminator as a key, so it would be used unless the IDL writer says explicitly not to using @key(FALSE). Since this isn't none of this actually standardized I'm just taking the opportunity to try to clarify how this should work and find out what the limits, if any, are there on implied keys. My takeaway from RTI's documentation is that they will use as much as possible as a key. However, I should add that the documentation actually doesn't say what would happen in this situation, so ideally I would like this brought up with the rest of the spec issue on implied keys.