[
https://issues.apache.org/jira/browse/AURORA-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15210587#comment-15210587
]
Bill Farner commented on AURORA-1651:
-------------------------------------
Some background on the semi-recent introduction of this behavior can be found
in AURORA-1476 the reviews linked within.
This change to the {{I*}} classes was done to move the manipulation to the
edges, rather than let it happen implicitly through a database round-trip. The
manipulation via DB round-trip bit us most acutely in code that attempts to
de-duplicate objects ({{TaskConfig}}) that are otherwise a dominant consumer of
storage. The alternative approach of nullable database columns was discarded
as further from ideal.
Happy to expound further.
> 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)
