[
https://issues.apache.org/jira/browse/AURORA-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15210597#comment-15210597
]
John Sirois edited comment on AURORA-1651 at 3/24/16 5:26 PM:
--------------------------------------------------------------
Would you object to ripping off the bandaid and killing {{isSet}} methods from
the {{I*}} generated classes completely? This would eliminate the confusing
difference and make it clear in a refactor from thrift struct to {{I*}} that
you needed to handle the {{isSet}} in some other way alltogether.
was (Author: jsirois):
Would you object to ripping off the bandaid and killing {{isSet}} methods from
the {{I*} generated classes completely? This would eliminate the confusing
difference and make it clear in a refactor from thrift struct to {{I*}} that
you needed to handle the {{isSet}} in some other way alltogether.
> I* entity objects are lossy for primitive isSet-ness
> ----------------------------------------------------
>
> Key: AURORA-1651
> URL: https://issues.apache.org/jira/browse/AURORA-1651
> Project: Aurora
> Issue Type: Bug
> Components: Build, Scheduler
> Reporter: John Sirois
>
> For example, {{ITaskQuery}} sets the {{offset}} and {{limit}} like so:
> {noformat}
> this.offset = wrapped.getOffset();
> this.limit = wrapped.getLimit();
> {noformat}
> There is no check to see if {{wrapped.isSetOffset}} or {{wrapped.isSetLimit}}
> paired with use of a nullable wrapper type ({{Integer}} vs {{int}} in this
> case) or an {{isSet}} bit vector. As a result a round trip from thrift
> struct to entity to thrift struct loses {{isSet}}-ness.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
