Add a way to set the Kind from Embeddable #164

[athieriot]

To explain a bit more about issue #164, we have this use case where we use a Wrapper that embed a generic
object in one of its field.

@Entity
public class Wrapper {

   @Embedded
   private Interface content;

   ...
}

The content can be of any subtype of Interface (some of them will be
outside of our control) and the Kind value can change with any of
these subtypes.

This Pull Request allow a developer to provide an Embeddable class
that will override the Kind of the enclosing Entity.

It will look like this:

@Embeddable
@OverrideKind(kind = "mycontent")
public class MyContent implement Interface {

   ...
}

[sai-pullabhotla]

@athieriot - thanks for submitting this Pull Request. Have a question -

If you are able to annotate the Embeddable with a OverrideKind, why not annotate it as an Entity? Does the "Wrapper" have any other data elements other than an Embedded Content?

[athieriot]

Yes, the wrapper class contains more data. Primarily some metadata we manage as well as revision informations. Le mar. 8 août 2017 à 17:33, Sai Pullabhotla <[email protected]> a écrit :

…

@athieriot <https://github.com/athieriot> - thanks for submitting this Pull Request. Have a question - If you are able to annotate the Embeddable with a OverrideKind, why not annotate it as an Entity? Does the "Wrapper" have any other data elements other than an Embedded Content? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#165 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAoZjXYhBWZyEhjQTq0393_dY9Ls9R4hks5sWI3EgaJpZM4Ovn_3> .

[sai-pullabhotla]

Does something like the below works for you?

@MappedSuperClass
class Document {
    //Common Metadata fields
}

@Entity 
class MyContent1 extends Document {
    //Specific fields for MyContent1
}

@Entity 
class MyContent2 extends Document {
    //Specific fields for MyContent2
}

[athieriot]

Well. It is something we are considering but, unfortunately, we can't apply such a change for the time being as we break our API compatibility.

…

On 9 August 2017 at 14:20, Sai Pullabhotla ***@***.***> wrote: Does something like the below works for you? @MappedSuperClass class Document { //Common Metadata fields } @entity class MyContent1 extends Document { //Specific fields for MyContent1 } @entity class MyContent2 extends Document { //Specific fields for MyContent2 } — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#165 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAoZjfOPZtXc1geP_3anINq73oFMzB1Qks5sWbIrgaJpZM4Ovn_3> .

[sai-pullabhotla]

@athieriot - I think you should eventually use the MappedSuperClass/Entity for your needs. This PullRequest looks like a temporary solution that addresses your specific needs. For now, I will go ahead and close this PullRequest, this means you would have to use the modified code from your forked repo. Let me know if you have any further questions or comments.

[athieriot]

Thank you for your feedback, it does make sense from a library point of view.

One other thing we are especially looking at is to be able to use immutable objects.
So we might give a crack at implementing this issue: #49.

If you have any advice of if there is anything wrong with this current PR (Style, tests, doc) that you wouldn't want to see please tell !

[sai-pullabhotla]

It would be great to have support for the immutable fields within an entity. Once you have the implementation, we can work out any minor changes. Comments/JavaDoc is important. Use the default Eclipse code formatter settings. I will go ahead and close this now.