Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
HBase >> mail # dev >> Does compatibility between versions also mean binary compatibility?


+
Jean-Daniel Cryans 2013-04-04, 20:20
+
Andrew Purtell 2013-04-04, 22:21
+
Stack 2013-04-04, 22:48
+
lars hofhansl 2013-04-04, 22:59
+
Jean-Daniel Cryans 2013-04-04, 23:06
+
Stack 2013-04-05, 06:35
+
James Taylor 2013-04-04, 23:29
+
Andrew Purtell 2013-04-05, 00:53
+
James Taylor 2013-04-06, 20:11
+
Andrew Purtell 2013-04-09, 00:40
+
Enis Söztutar 2013-04-09, 03:02
+
Elliott Clark 2013-04-09, 04:49
+
Jean-Daniel Cryans 2013-04-15, 18:06
Copy link to this message
-
Re: Does compatibility between versions also mean binary compatibility?
Good points James.

I think that regarding binary compatibility, we need to be at least
backward compatible.

If I understand your first point correctly, code that compiles against
0.94.4 to use the new features added there wouldn't even compile against
0.94.3, and I find this reasonable. I'm pretty sure that most here think
the same way.

Regards,

J-D
On Thu, Apr 4, 2013 at 4:29 PM, James Taylor <[EMAIL PROTECTED]> wrote:

> The binary compat is a slippery slope. It'd be a bummer if we couldn't
> take advantage of all the innovation you guys are doing. At the same time,
> it's tough to require the Phoenix user community, for example, to upgrade
> their HBase servers to be able to move to the latest version of Phoenix. I
> don't know what the right answer is, but here are a couple of concrete
> cases:
> - between 0.94.3 and 0.94.4, new methods were introduced on RegionScanner.
> Often coprocessors will have their own implementation of these so that they
> can aggregate in the postScannerOpen. Though this broke binary compat, it
> improved scan performance as well. Where does the binary compatible line
> stop?
> - between 0.94.3 and 0.94.4, the class loading changed for coprocessors.
> If a coprocessor was on the classpath, it didn't matter what the jar path
> was, it would load. In 0.94.4, that was no longer the case - if the jar
> path was invalid, the coprocessor would no longer load. Though this broke
> compatibility, it was a good cleanup for the class loading logic. Call it a
> bug fix or a change in behavior, but either way it was an incompatible
> change. Is a change in behavior that causes incompatibilities still meet
> the binary compatible criteria?
> - between 0.94.4 and 0.94.5, the essential column family feature was
> introduced. This is an example of one that is binary compatible. We're able
> to take advantage of the feature and maintain binary compatibility with
> 0.94.4 (in which case the feature simple wouldn't be available).
>
> Maybe if we just explicitly identified compatibility issues, that would be
> a good start? We'd likely need a way to find them, though.
>
>     James
>
>
> On 04/04/2013 03:59 PM, lars hofhansl wrote:
>
>> I agree we need both, but I'm afraid that ship has sailed.
>> It's not something we paid a lot of attention to especially being
>> forward-binary-compatible. I would guess that there will be many more of
>> these issues.
>>
>> Also, we have to qualify this statement somewhere. If you extend
>> HRegionServer you cannot expect compatibility between releases. Of course
>> that is silly, but it serves the point I am making.
>>
>> For client visible classes (such as in this case) we should make it work,
>> we identifies issues with Filters and Coprocessors in the past and kept
>> them binary compatible on a best effort basis.
>>
>>
>> TL;DR: Let's fix this issue, and be wary of more such issues.
>>
>>
>> -- Lars
>>
>>
>>
>> ______________________________**__
>>   From: Andrew Purtell <[EMAIL PROTECTED]>
>> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
>> Sent: Thursday, April 4, 2013 3:21 PM
>> Subject: Re: Does compatibility between versions also mean binary
>> compatibility?
>>   "Compatible" implies both to my understanding of the term, unless
>> qualified.
>>
>> I don't think we should qualify it. This looks like a regression to me.
>>
>>
>> On Thu, Apr 4, 2013 at 1:20 PM, Jean-Daniel Cryans <[EMAIL PROTECTED]
>> >wrote:
>>
>>  tl;dr should two compatible versions be considered both wire and
>>> binary compatible or just the former?
>>>
>>> Hey devs,
>>>
>>> 0.92 is compatible with 0.94, meaning that you can run a client for
>>> either against the other and you can roll restart from 0.92 to 0.94.
>>>
>>> What about binary compatibility? Meaning, can you run user code
>>> compiled against 0.92 with 0.94's jars?
>>>
>>> Unfortunately, the answer is "no" in this case if you invoke setters
>>> on HColumnDescriptor as you'll get:
>>>
>>> java.lang.NoSuchMethodError:
>>> org.apache.hadoop.hbase.**HColumnDescriptor.**setMaxVersions(I)V
+
Elliott Clark 2013-04-05, 23:06
+
Nick Dimiduk 2013-04-04, 22:06