Some operators like external sort or window functions will double check to
make sure the schema really changed before throwing a schema-change
exception. But others, like streaming aggregate or hash aggregate, don't
check and will throw a schema-change exception even if the schema didn't
really change.
so I guess it's a combination of both
On Fri, Oct 2, 2015 at 11:26 AM, Daniel Barclay <dbarclay@maprtech.com>
wrote:
> Is OK_NEW_SCHEMA intended to signal that the new schema is actually
> changed from any previous schema, or is it intended only to signal
> that there's a new (report of the) schema, but the new schema isn't
> necessarily different from any previous schema)?
>
>
> Are callers (of XxxBatch next() methods) that receive OK_NEW_SCHEMA
> responsible for checking whether the new schema is the same as the old
> schema (or, more generally, can be handled by the caller) and avoiding
> throwing a schema-change exception in that case?
>
> Or are callees (XxxBatch next() methods) responsible for not returning
> OK_NEW_SCHEMA if the new schema is the same as the previous schema?
>
> (Or is it some combination?)
>
> Thanks,
> Daniel
> --
> Daniel Barclay
> MapR Technologies
>
--
Abdelhakim Deneche
Software Engineer
<http://www.mapr.com/>
Now Available - Free Hadoop On-Demand Training
<http://www.mapr.com/training?utm_source=Email&utm_medium=Signature&utm_campaign=Free%20available>
|