Thanks, Taras! I think this definitely should be included in the release notes and somewhere in the documentation.
On Tue, Feb 21, 2017 at 2:50 AM, Taras Ledkov <tled...@gridgain.com> wrote: > I've updated the issue: https://issues.apache.org/jira/browse/IGNITE-3469 > with two lists of deprecated API: public and private. > > Please take a look. I would create sub tasks for each to make review > simpler then one huge patch that contains the whole refactoring. > > The list of the deprecated public class / methods / properties: > > - two methods IgniteCluster.mapKeyToNode - the removing is simple because > its are used rare; > - IgniteCache.randomEntry - the removing is simple because it is used rare; > - The system flags: > - IGNITE_BINARY_SORT_OBJECT_FIELDS; > - IGNITE_BINARY_DONT_WRAP_TREE_STRUCTURES; > - IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT - not used in the > projects now. > - CacheTypeMetadata; > - Classes related with AffinityNodeHashResolver; > - Backup filters for affinity functions; > - RandomEvictionPolicy; > - ContinuousQuery.setRemoteFilter; > - CacheStore.sessionEnd; > - CacheAbstractJdbcStore.translateFields; > - CacheJdbcPojoStoreFactory.setDataSource; > - CacheConfiguration properties: transactionManagerLookupClassName and > {rebalanceThreadPoolSize}}; > - ConnectorConfiguration.sslContextFactory property; > - FileSystemConfiguration properties: > - fragmentizerLocalWritesRatio; > - trashPurgeTimeout; > - dualModePutExecutorService; > - dualModePutExecutorServiceShutdown; > - dualModeMaxPendingPutsSize; > - IgniteConfiguration properties: > - nodeId; > - DFLT_PUBLIC_KEEP_ALIVE_TIME; > - DFLT_PUBLIC_THREADPOOL_QUEUE_CAP; > - DFLT_SYSTEM_MAX_THREAD_CNT; > - DFLT_SYSTEM_KEEP_ALIVE_TIME; > - DFLT_UTILITY_KEEP_ALIVE_TIME; > - DFLT_SYSTEM_THREADPOOL_QUEUE_CAP; > - TransactionConfiguration properties: > - txSerializableEnabled; > - txManagerLookupClassName; > - Several methods at the IgfsPath class: empty constructor, root() and > isSame methods; > - IgniteSpiContext: methods addMessageListener, removeMessageListener; > - TcpCommunicationSpi properties: > - connectionBufferSize; > - connectionBufferFlushFrequency; > - minimumBufferedMessageCount; > - StreamTupleExtractor class and relations; > - ignite-hadoop: Several constructors of the IgniteHadoopIgfsSecondaryFileS > ystem; > - ignite-yarn: ApplicationMaster.getContainers(). > > The list of the deprecated private class / methods / properties: > > - Classes are retated to the GridSslContextFactory; > - JdbcConnection related classes; > - GridCacheUtils.cheatCache; > - GridCacheCommittedTxInfo; > - GridDistributedTxFinishRequest: syncCommit, syncRollback; > - GridDhtPartitionDemander: demandLock, dmIdx, worker, SupplyMessage, > DemandWorker; > - One of the constructors of the GridDhtPartitionFullMap; > - GridDhtPartitionMap; > - GridDhtPartitionSupplier old listeners & old demand message; > - AffinityTask.affinityKey() > - GridQueryRequest; > - One of the constructors of GridLeanSet; > - Several methods at the IgniteUtils; > - Several methods at the GridFunc; > - GridTupleV; > - PlatformDotNetBinaryTypeConfiguration.isKeepDeserialized(); > - ServerImpl.RingMessageWorker.processNodeAddedMessage; > - TcpDiscoverySpi.versionCheckFailed; > > > On 08.12.2016 1:04, Denis Magda wrote: > >> I would remove as much as possible and prepare a migration guide as >> Sergey K. suggests below. >> >> In any case, we will stick to the flexible approach. As the next step I >> would split all the existed APIs in 2 groups. The first group will be for >> the APIs that will be deleted and we will provide instructions in the >> migration guide on how to migrate from them. The second group will be for >> those that will be left. >> >> Actually, there is an already existed ticket for this >> https://issues.apache.org/jira/browse/IGNITE-3469 < >> https://issues.apache.org/jira/browse/IGNITE-3469> >> >> — >> Denis >> >> On Dec 7, 2016, at 10:12 AM, Sergey Kozlov <skoz...@gridgain.com> wrote: >>> >>> I would remind that Apache Ignite 1.0.0 has been released 20 months ago >>> and >>> probably 2.0 will be rolled out close to the second anniversary of >>> initial >>> release. It's right time to remove deprecated API and provide for users >>> the >>> clear ways for migration 1.x to 2.0. >>> >>> I think we could create a wiki page for users who can recompile their >>> applications, list all deprecated API calls and provide migration's >>> tips/tricks from deprecated features to new ones (something like the >>> table >>> with columns "Deprecated API call for 1.x", "API call for >>> 2.0/workaround"). >>> >>> >>> >>> On Wed, Dec 7, 2016 at 11:36 AM, Yakov Zhdanov <yzhda...@apache.org> >>> wrote: >>> >>> Agree with Vladimir that we should use flexible approach and should avoid >>>> any possible harm here, but cleaning out most of deprecations is the >>>> way to >>>> go, IMO. There are about 90 occurrences of "deprecated" in the project >>>> and >>>> most of them are not very hard to remove. Moreover, we have, for >>>> example, >>>> setRemoteFilter(CacheEntryEventSerializableFilter<K, V>). Using this >>>> method >>>> is error prone. We should remove it so none can use it. >>>> >>>> Cleaning up and renovating are good. This allows us to see what can be >>>> done >>>> better and also encourages users to move forward. >>>> >>>> --Yakov >>>> >>>> 2016-12-07 15:22 GMT+07:00 Vladimir Ozerov <voze...@gridgain.com>: >>>> >>>> Igniters, >>>>> >>>>> Release Apache Ignite 2.0 is already planned and being discussed. >>>>> >>>> Normally >>>> >>>>> we do not brake compilation between minor releases, and if some method >>>>> on >>>>> public API should not be used anymore we mark it as *deprecated*. But >>>>> we >>>>> >>>> do >>>> >>>>> not have such a rule for major releases. The question is whether we are >>>>> going to break compilation and remove deprecated methods from public >>>>> API >>>>> >>>> in >>>> >>>>> Apache ignite 2.0 or not. There are several extreme approaches to this. >>>>> >>>>> First, we can declare that we cleanup all deprecations and remove them. >>>>> This will result in clean and consistent API and simplify further >>>>> development. But it might slowdown adoption of Apache Ignite 2.0 >>>>> because >>>>> users will be reluctant switching to newer version because they will >>>>> have >>>>> to fix compilation, re-deploy their apps, etc.. >>>>> >>>>> Second, we can say that we must avoid breaking compilation at all costs >>>>> >>>> and >>>> >>>>> retain deprecated methods. This approach might be better for users, for >>>>> harder to maintain for Ignite developers. With this approach users will >>>>> migrate to 2.0 quicker. >>>>> >>>>> My opinion is that we must choose flexible approach and decide whether >>>>> to >>>>> keep deprecation or not separately for every piece of API, depending on >>>>> possible impact on both users and Ignite developers. But normally I >>>>> would >>>>> leave deprecation unless there is a strong reason to remove it. >>>>> >>>>> Thoughts? >>>>> >>>>> Vladimir. >>>>> >>>>> >>> >>> -- >>> Sergey Kozlov >>> GridGain Systems >>> www.gridgain.com >>> >> >> > -- > Taras Ledkov > Mail-To: tled...@gridgain.com > >
