aurora-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Farner (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AURORA-1651) I* entity objects are lossy for primitive isSet-ness
Date Thu, 24 Mar 2016 17:18:25 GMT

    [ 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)

Mime
View raw message