[
https://issues.apache.org/jira/browse/ATLAS-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153459#comment-15153459
]
Hemanth Yamijala commented on ATLAS-476:
----------------------------------------
Proposal for a fix. I'm new to this area, so please review the approach before
I get down too much into implementation.
The following changes would likely fix this issue:
* Introduce a {{TypeSystem.verifyUpdate}} - this would carry out steps 1 to 5
of the current {{TypeSystem.updateTypes}} and return a list of added types. But
it would not change the TypeSystem state.
* Introduce a {{TypeSystem.updateTypes}} - this would update TypeSystem state.
* Modify {{DefaultMetadataService.update}} as follows:
** First call {{TypeSystem.verifyUpdate}}
** Then make changes to Index and Type store.
** If all good, call {{TypeSystem.updateTypes}} passing in the list of added
types from {{TypeSystem.verifyUpdate}}.
The main issue in this change is what I've already put in the earlier comment:
that {{TypeStore.store}} currently takes a *modified* {{TypeSystem}} object,
looks up the added or existing types and uses them to update the type graph. We
have to modify this API to take a list of added / updated types and the
*unmodified* type system. Every existing lookup in this API must first look
through the added types and then the unmodified type system.
Changing the interface of {{TypeStore.store}} to be like this doesn't seem a
bad change IMO and its not used at many places - so its OK.
For completeness, this proposal does not still address the issue of rolling
back changes to the Index. Probably we can attack that after we are done with
this change to manage the complexity of the patch.
Also, the other option I considered was to maintain the existing flow as-is,
but keep track of the modification made to the {{TypeSystem.updateTypes}} and
have an undo method to rollback the changes on error. However, such state
should be maintained against the context of the call etc. - basically
introducing transactionality into the Cache. That clearly seemed an overly
complex solution.
> Update type attribute with Reserved characters updated the original type as
> unknown
> -----------------------------------------------------------------------------------
>
> Key: ATLAS-476
> URL: https://issues.apache.org/jira/browse/ATLAS-476
> Project: Atlas
> Issue Type: Bug
> Affects Versions: trunk
> Environment: sandbox
> Reporter: Chethana
> Assignee: Hemanth Yamijala
> Priority: Blocker
> Fix For: 0.7-incubating
>
> Attachments: 1.log
>
>
> create a type with required attribute
> try to get this type created - the type data is returned
> try update this type by adding attribute with attribute name consisting of a
> reserved character eg:test$
> this throws exception.
> Now use to get call to get the previously created type
> Expected:
> The type should not be updated.
> Actual:
> "error": "Unknown datatype: className_update_vsvrbzqaqg",
> "stackTrace": "org.apache.atlas.typesystem.exception.TypeNotFoundException:
> Unknown datatype: className_update_vsvrbzqaqg\n\tat
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
