Re: Unable to insert data into table after altering the table
Hi, That's a known limitation caused by the fact that Ignite keeps metadata even after a column is fully dropped. This to be addressed with the next major release - Ignite 3.0. As for now, *When this happens _and you are still in development_, you need to go into the* *file system and remove the following directories: `marshaller/`, `db/`, and `wal/`* *located in the Ignite working directory (`db` and `wal` might be located in other* *places if you have redefined their location).* *However, if you are _in production_ then instead of changing field types, add a* *new field named differently to your object model and remove the old one. This operation is fully* *supported. At the same time, the `ALTER TABLE` command can be used to add new* *columns or remove existing ones at run time. * - Denis On Fri, Aug 2, 2019 at 1:46 PM radha jai wrote: > Hi, > Insertion is failing, after altering the table. > Followed below steps: > > -> CREATE TABLE student (id_ VARCHAR, firstName VARCHAR, lastName VARCHAR, > birthDate TIMESTAMP, height DOUBLE, PRIMARY KEY(id)) > -> INSERT INTO student (id, firstName, lastName, birthDate, height) VALUES > (1000, 'huxt', 'abx', CURRENT_TIMESTAMP(), 5.6); > -> ALTER TABLE student DROP COLUMN birthDate; > -> ALTER TABLE student ADD COLUMN birthDate VARCHAR; > -> INSERT INTO student (id, firstName, lastName, birthDate, height) VALUES > (1001, 'luan', 'qwst', '11223', 6.6); > > Getting below error: > Error: class org.apache.ignite.binary.BinaryObjectException: Wrong value > has been set > [typeName=SQL_PUBLIC_STUDENT_e910ba3a_3a65_4d53_9265_8c12a9b0bac3, > fieldName=BIRTHDATE, fieldType=Timestamp, assignedValueType=String] > (state=5,code=1) > > Issues faced: > -> unable to insert the data after modifying the datatype of the field in a > table. > -> If i do " select * from student;" , I am seeing the old data being > inserted for the birthdate column, after dropping birthdate colmun and > adding the colmn with the same name but different datatype. > > Is this a know issue? Or soemthing i am doing wrong. > If it is a know issue please provide the workaround. > > Thanks > radha >
Unable to insert data into table after altering the table
Hi, Insertion is failing, after altering the table. Followed below steps: -> CREATE TABLE student (id_ VARCHAR, firstName VARCHAR, lastName VARCHAR, birthDate TIMESTAMP, height DOUBLE, PRIMARY KEY(id)) -> INSERT INTO student (id, firstName, lastName, birthDate, height) VALUES (1000, 'huxt', 'abx', CURRENT_TIMESTAMP(), 5.6); -> ALTER TABLE student DROP COLUMN birthDate; -> ALTER TABLE student ADD COLUMN birthDate VARCHAR; -> INSERT INTO student (id, firstName, lastName, birthDate, height) VALUES (1001, 'luan', 'qwst', '11223', 6.6); Getting below error: Error: class org.apache.ignite.binary.BinaryObjectException: Wrong value has been set [typeName=SQL_PUBLIC_STUDENT_e910ba3a_3a65_4d53_9265_8c12a9b0bac3, fieldName=BIRTHDATE, fieldType=Timestamp, assignedValueType=String] (state=5,code=1) Issues faced: -> unable to insert the data after modifying the datatype of the field in a table. -> If i do " select * from student;" , I am seeing the old data being inserted for the birthdate column, after dropping birthdate colmun and adding the colmn with the same name but different datatype. Is this a know issue? Or soemthing i am doing wrong. If it is a know issue please provide the workaround. Thanks radha
[jira] [Created] (IGNITE-12040) IgniteNodeStoppedDuringDisableWALTest.test[AFTER_DISABLE_WAL] fails in MVCC mode
Ivan Pavlukhin created IGNITE-12040:
---
Summary:
IgniteNodeStoppedDuringDisableWALTest.test[AFTER_DISABLE_WAL] fails in MVCC mode
Key: IGNITE-12040
URL: https://issues.apache.org/jira/browse/IGNITE-12040
Project: Ignite
Issue Type: Bug
Components: mvcc
Reporter: Ivan Pavlukhin
IgniteNodeStoppedDuringDisableWALTest.test[AFTER_DISABLE_WAL] fails in MVCC
mode.
{noformat}
[2019-08-02
12:59:35,836][ERROR][test-runner-#7379%wal.IgniteNodeStoppedDuringDisableWALTest%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=CRITICAL_ERROR, err=class
o.a.i.i.processors.cache.persistence.StorageException: Failed to read record by
pointer [ptr=FileWALPointer [idx=0, fileOff=0, len=0], rec=IgniteBiTuple
[val1=FileWALPointer [idx=0, fileOff=29, len=29], val2=MemoryRecoveryRecord
[time=1564739950672, super=WALRecord [size=29, chainSize=0, pos=FileWALPointer
[idx=0, fileOff=29, len=29], type=MEMORY_RECOVERY]]
class org.apache.ignite.internal.processors.cache.persistence.StorageException:
Failed to read record by pointer [ptr=FileWALPointer [idx=0, fileOff=0, len=0],
rec=IgniteBiTuple [val1=FileWALPointer [idx=0, fileOff=29, len=29],
val2=MemoryRecoveryRecord [time=1564739950672, super=WALRecord [size=29,
chainSize=0, pos=FileWALPointer [idx=0, fileOff=29, len=29],
type=MEMORY_RECOVERY
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.read(FileWriteAheadLogManager.java:913)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.performBinaryMemoryRestore(GridCacheDatabaseSharedManager.java:2233)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:795)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:5461)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1167)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1987)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1687)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1110)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:608)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:970)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:911)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:899)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:865)
at
org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteNodeStoppedDuringDisableWALTest.testStopNodeWithDisableWAL(IgniteNodeStoppedDuringDisableWALTest.java:203)
at
org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteNodeStoppedDuringDisableWALTest.test(IgniteNodeStoppedDuringDisableWALTest.java:114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2069)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (IGNITE-12039) CacheGroupMetricsMBeanTest.testCacheGroupMetrics fails in MVCC mode
Ivan Pavlukhin created IGNITE-12039:
---
Summary: CacheGroupMetricsMBeanTest.testCacheGroupMetrics fails in
MVCC mode
Key: IGNITE-12039
URL: https://issues.apache.org/jira/browse/IGNITE-12039
Project: Ignite
Issue Type: Bug
Components: mvcc
Reporter: Ivan Pavlukhin
CacheGroupMetricsMBeanTest.testCacheGroupMetrics fails in MVCC mode.
{noformat}
java.lang.AssertionError: Renting partitions count when node returns not equals
to moved partitions when node left
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:28)
at
org.apache.ignite.internal.processors.cache.CacheGroupMetricsMBeanTest.testCacheGroupMetrics(CacheGroupMetricsMBeanTest.java:330)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2069)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
Re: [MTCGA]: new failures in builds [4172317, 4172313, 4172278] needs to be handled
I've created a ticket for repair [1] and start working on it. [1] https://issues.apache.org/jira/browse/IGNITE-12038 чт, 4 июл. 2019 г. в 15:54, Alexei Scherbakov : > Dmitry, > > I'm aware of failing tests, will check in nearest time. > > пн, 1 июл. 2019 г. в 22:04, Dmitriy Pavlov : > >> I've checked Pavel's change and it is .NET only >> https://issues.apache.org/jira/browse/IGNITE-11867 >> I guess this change may have an effect on other tests >> >> пн, 1 июл. 2019 г. в 21:24, Dmitriy Pavlov : >> >> > Alexey, Pavel, could you please double check reasons for the failure? >> > >> > пн, 1 июл. 2019 г. в 21:11, : >> > >> >> Hi Igniters, >> >> >> >> I've detected some new issue on TeamCity to be handled. You are more >> >> than welcomed to help. >> >> >> >> If your changes can lead to this failure(s): We're grateful that you >> >> were a volunteer to make the contribution to this project, but things >> >> change and you may no longer be able to finalize your contribution. >> >> Could you respond to this email and indicate if you wish to continue >> and >> >> fix test failures or step down and some committer may revert you >> commit. >> >> >> >> *New stable failure of a flaky test in master >> >> LocalWalModeChangeDuringRebalancingSelfTest.testWithExchangesMerge >> >> >> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-6585115376754732686&branch=%3Cdefault%3E&tab=testDetails >> >> Changes may lead to failure were done by >> >> - alexey.scherbak...@gmail.com >> >> https://ci.ignite.apache.org/viewModification.html?modId=886764 >> >> - ptupit...@apache.org >> >> https://ci.ignite.apache.org/viewModification.html?modId=886762 >> >> >> >> *New stable failure of a flaky test in master >> >> >> GridCacheRebalancingWithAsyncClearingMvccTest.testPartitionClearingNotBlockExchange >> >> >> >> >> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-7007912051428984819&branch=%3Cdefault%3E&tab=testDetails >> >> Changes may lead to failure were done by >> >> - alexey.scherbak...@gmail.com >> >> https://ci.ignite.apache.org/viewModification.html?modId=886764 >> >> - ptupit...@apache.org >> >> https://ci.ignite.apache.org/viewModification.html?modId=886762 >> >> >> >> *New stable failure of a flaky test in master >> >> GridCacheRebalancingAsyncSelfTest.testComplexRebalancing >> >> >> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-8829809273565657995&branch=%3Cdefault%3E&tab=testDetails >> >> Changes may lead to failure were done by >> >> - alexey.scherbak...@gmail.com >> >> https://ci.ignite.apache.org/viewModification.html?modId=886764 >> >> - ptupit...@apache.org >> >> https://ci.ignite.apache.org/viewModification.html?modId=886762 >> >> >> >> - Here's a reminder of what contributors were agreed to do >> >> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute >> >> - Should you have any questions please contact >> >> dev@ignite.apache.org >> >> >> >> Best Regards, >> >> Apache Ignite TeamCity Bot >> >> https://github.com/apache/ignite-teamcity-bot >> >> Notification generated at 21:10:24 01-07-2019 >> >> >> > >> > > > -- > > Best regards, > Alexei Scherbakov > -- Best regards, Alexei Scherbakov
[jira] [Created] (IGNITE-12038) Fix several failing tests after IGNITE-10078
Alexei Scherbakov created IGNITE-12038: -- Summary: Fix several failing tests after IGNITE-10078 Key: IGNITE-12038 URL: https://issues.apache.org/jira/browse/IGNITE-12038 Project: Ignite Issue Type: Bug Reporter: Alexei Scherbakov Assignee: Alexei Scherbakov Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-12037) Ignore tests in MVCC PDS 3 suite canonically
Ivan Pavlukhin created IGNITE-12037:
---
Summary: Ignore tests in MVCC PDS 3 suite canonically
Key: IGNITE-12037
URL: https://issues.apache.org/jira/browse/IGNITE-12037
Project: Ignite
Issue Type: Task
Components: mvcc
Reporter: Ivan Pavlukhin
Assignee: Ivan Pavlukhin
Currently tests in IgnitePdsMvccTestSuite3 are ignored using following
construction:
{code}
// TODO https://issues.apache.org/jira/browse/IGNITE-11937
ignoredTests.add(IgnitePdsContinuousRestartTest.class);
ignoredTests.add(IgnitePdsContinuousRestartTestWithExpiryPolicy.class);
{code}
But IgnitePdsContinuousRestartTestWithExpiryPolicy is already ignored (as
ExpiryPolicy is not supported for MVCC caches). And it worth to ignore tests in
IgnitePdsContinuousRestartTest explicitly so they will be listed as ignored
tests after execution.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (IGNITE-12036) Changing baseline via set command may cause NPEs if configured NodeFilter takes node attributes into account
Alexander Lapin created IGNITE-12036: Summary: Changing baseline via set command may cause NPEs if configured NodeFilter takes node attributes into account Key: IGNITE-12036 URL: https://issues.apache.org/jira/browse/IGNITE-12036 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin Assignee: Alexander Lapin VisorBaselineTask doesn't allow to add() offline baseline node, but allows to set() collection of nodes where at least one is offline and doesn’t belong to current BLT. We should prohibit passing offline nodes to setBaselineTopology(…) (in case they are not part of current BLT): otherwise we won't be able to calculate affinity in case NodeFilter is configured. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
Re: Deprecate\remove REBALANCE_OBJECT_LOADED cache event
Igniters, I've created a ticket [1]. [1] https://issues.apache.org/jira/browse/IGNITE-12035 On Thu, 1 Aug 2019 at 10:55, Pavel Kovalenko wrote: > > Hello Maxim, > > Thank you for researching this. > It seems those events can be used as an interceptor for the rebalance > process to make some extra actions after the entry is rebalanced. > However, I don't see any real usages despite tests. Most likely > functionality that used such rebalance events no longer exists. > I see no reasons to have it anymore. > +1 for removing in 2.8 > > > ср, 31 июл. 2019 г. в 20:54, Maxim Muzafarov : > > > Igniters, > > > > > > I've faced with EVT_CACHE_REBALANCE_OBJECT_LOADED [1] and > > EVT_CACHE_REBALANCE_OBJECT_UNLOADED [2] cache events and not fully > > understand their general purpose. Hope someone from the community can > > clarify to me the initial idea of adding these events. > > > > The first - it seems to me that these events are completely Ignite > > internal thing. Why the user should be able to subscribe to such > > events? (not related to tracking cache keys metrics). Once the data is > > loaded to cache, I see no reasons to notifying the user about moving > > cache keys from one node to another if the cluster topology changed. > > It's up to Ignites mission to keep data consistency in any cases. > > > > The second - I haven't found any real usages on GitHub\Google of these > > events. Most of the examples are related to our community members and > > Ignites documentation. > > > > The third - Correct me if I am wrong, but subscribing for Ignites > > events can have a strong influence on the cluster performance. So > > fewer events available to users the better performance will be. > > > > > > I think these events can be easily removed in the next 2.8 release. > > WDYT? Am I missing something? > > > > [1] > > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/events/EventType.html#EVT_CACHE_REBALANCE_OBJECT_LOADED > > [2] > > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/events/EventType.html#EVT_CACHE_REBALANCE_OBJECT_UNLOADED > >
[jira] [Created] (IGNITE-12035) Deprecate EVT_CACHE_REBALANCE_OBJECT_LOADED cache events
Maxim Muzafarov created IGNITE-12035: Summary: Deprecate EVT_CACHE_REBALANCE_OBJECT_LOADED cache events Key: IGNITE-12035 URL: https://issues.apache.org/jira/browse/IGNITE-12035 Project: Ignite Issue Type: Improvement Reporter: Maxim Muzafarov Assignee: Maxim Muzafarov Fix For: 2.8 Events # [EVT_CACHE_REBALANCE_OBJECT_LOADED|https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/events/EventType.html#EVT_CACHE_REBALANCE_OBJECT_LOADED] # [EVT_CACHE_REBALANCE_OBJECT_UNLOADED|https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/events/EventType.html#EVT_CACHE_REBALANCE_OBJECT_UNLOADED] currently not used and should be deprecated for the _2.8_ release and removed in _3.0_. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-12034) containsKey() does not work correct in some cases
Kanunnikov Pavel created IGNITE-12034:
-
Summary: containsKey() does not work correct in some cases
Key: IGNITE-12034
URL: https://issues.apache.org/jira/browse/IGNITE-12034
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7.5
Reporter: Kanunnikov Pavel
Attachments: reproducing_example.java
{{containsKey()}} method does not work correct in some cases. Steps to
reproduce:
# create cache with {{CacheMode.LOCAL}} cache mode and
{{CacheAtomicityMode.TRANSACTIONAL}} atomicity mode
# start transaction
# put some entry to the cache
# commit and close transaction
# start another new transaction
# try to call {{containsKey()}} for the existing entry (which has been added at
step 3)
# check result. It will be {{false}}. But entry with such key exists! We can
also get it by {{get() method}}.
# commit/rollback and close transaction
Bug checked in versions: {{2.6.0}}, {{2.7.0}}, {{2.7.5}}.
Simple reproducing example attached to this issue.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
