Hello, Igniters! I am not familiar with the Ignite's thin client.
I'd suggest defining tests scenarios first, to understand what we need for testing. For example, our Compatibility Framework may be used for the following scenario: 1. Start node of a previously released version in separate JVM and fill data; 2. Start thin client of an actual version in local JVM then read and validate data; Opposite scenario with new nodes and previously released thin clients is possible too, but such tests will look difficult. If we need such scenarios, may be required to extend frameworks API to simplify coding. On Wed, Jun 6, 2018 at 2:41 PM, Dmitry Pavlov <dpavlov....@gmail.com> wrote: > Hi Vyacheslav, > > WDYT about applicability of PDS compatibiltiy framework for thin clients? > > Sincerely, > Dmitriy Pavlov > > ср, 6 июн. 2018 г. в 13:45, Vladimir Ozerov <voze...@gridgain.com>: >> >> Hi Nikolay, >> >> Huge +1 for automated compatibility tests. Luckily, we already did that >> for >> persistence, so probably we can re-use some infrastructure from there. >> >> On Wed, Jun 6, 2018 at 1:20 PM, Nikolay Izhikov <nizhi...@apache.org> >> wrote: >> >> > +1 From me. >> > >> > As I wrote in previous mail-threads, >> > I think we need to create test framework to be able to test >> > compatibility >> > for all clients we have. >> > >> > AFAIK, currently, there is no possibility to automatically check >> > compatibility. >> > >> > В Ср, 06/06/2018 в 11:39 +0300, Vladimir Ozerov пишет: >> > > Igniters, >> > > >> > > I'd like to discuss once again our compatibility policy for thin >> > > clients >> > > (.JDBC, ODBC, .NET, Java, etc.). We have no clear rules for now, so >> > > let's >> > > try to come to agreement. >> > > >> > > Normally database vendors work as follows: >> > > 1) There is a set of currently supported database versions >> > > 2) There is a set of currently supported JDBC/ODBC drivers >> > > 3) Every supported driver can work with every supported database (with >> > > little exclusions to this rule). >> > > >> > > That is, they are both backward and forward compatible. I can take >> > > latest >> > > Oracle's JDBC and some ancient Oracle version, and it will work, >> > > unless >> > > this version reached EOL and is no longer supported. And vice versa - >> > > new >> > > database, old driver, all is fine. >> > > >> > > This is ideal scheme which I'd like to see in Ignite, but: >> > > 1) Our protocol is still relatively young and evolve rapidly >> > > 2) AI does not have any maintenance releases, so we cannot define >> > > which >> > > version is supported and which is not. >> > > 3) >> > > >> > > I'd like to propose the following compatibility policy: >> > > 1) Maintain forward and backward compatibility between two nearest >> > > minor >> > > releases only. E.g. 2.5 can work with 2.4, 2.6 with 2.5, etc. >> > > 2) Think of more strict compatibility rules in AI 3.0 because at this >> > point >> > > our protocol will be stable enough. >> > > >> > > Thoughts? >> > > >> > > Vladimir. >> > -- Best Regards, Vyacheslav D.
