Skip to content
This repository has been archived by the owner on May 12, 2021. It is now read-only.

TAJO-2165: Add 'ALTER TABLE UNSET PROPERTY' statement to Tajo DDL #1036

Closed
wants to merge 29 commits into from

Conversation

dongjinleekr
Copy link
Contributor

No description provided.

…leType#UNSET_PROPERTY, AlterTableDescProto#property_keys 추가.
…bstractDBStore#alterTable에 위 메소드를 호출하는 기능 추가. 3. TestCatalog#testAlterTableName -> TestCatalog#testAlterTable 4. TestCatalog#createMockAlterTableUnsetProperty 헬퍼 메소드 추가. 5. TestCatalog#testAlterTable에 AbstractDBStore#unsetProperties 테스트 추가.
…talogUtil#unsetProperty를 호출해 주는 기능 추가.
@jihoonson
Copy link
Contributor

Thank you for your patch. I'll review soon. Would you please check the test failure?

@dongjinleekr
Copy link
Contributor Author

Updated! Thanks for your immediate response.

Followings are additional comments on this issue:

  1. During updating the (potentially) broken test, one question arose: is there any list of properties that should not be unset? If there are, it seems like we have to implement an additional feature to make them unset-proof. (for example, show error message when the user tries to unset some reserved properties.) Do you have any opinion on that? Or, is it better to query about this problem on dev mailing list?
  2. I omitted implementation for HiveCatalogStore - as you remember, it is a deprecated feature. (TAJO-1775)

… 존재성만을 검증하도록 수정. (instance별로 달라질 수 있는 값)
@jihoonson
Copy link
Contributor

Thank you for the quick update. Here are my answers.

  1. Basically, table properties are used for optional settings per table. So, every table property is optional, and tajo should be able to work with default property values if they are absent.
    However, among table properties, timezone is recently changed as a mandatory property of a table. So, currently I think it is the only one which should not be removed.
    The best solution seems to store the timezone value in the TableMeta or TableDesc instead of in the optional KeyValue set. But this would be better to be done in a separate ticket, and it would be enough to force timezone as unsettable here.
  2. The deprecated one is HCatalogStore, and HiveCatalogStore should be implemented. But, as you see, many functions of HiveCatalogStore are not implemented yet. I think it also would be better to do in a separate ticket.

@dongjinleekr
Copy link
Contributor Author

dongjinleekr commented Jul 6, 2016

Oh, my mistake. I confused HCatalogStore with HiveCatalogStore.

Let's sum up. The following is the list of tickets that should be opened. Some of them are from this discussion, and the others are what I found during this work. (I think it is better to implement disabling unset timezone feature on separate issue, not here.)

  1. [Major] Move timezone property from KeyValue set and disable to unset it. (Related: TAJO-1185, TAJO-1241)
  2. [Major, Umbrella] Implement missing HiveCatalogStore features.
  3. [Trivial] Remove AlterTableNode#clone - it has been commented out.

If you have any opinion, don't hesitate to comment to me. If you merge and close this request without any comments, I will regard it you accepted my proposal. Thanks again for your guidance! :)

@@ -552,6 +552,16 @@ public static AlterTableDesc setProperty(String tableName, KeyValueSet params, A
return alterTableDesc;
}

public static AlterTableDesc unsetProperty(String tableName, String[] propertyKeys, AlterTableType alterTableType) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

alterTableType must be UNSET_PROPERTY, so the last parameter looks unnecessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know. But I did it for the consistency with the other AlterTable methods: CatalogUtil#renameColumn, renameTable, addNewColumn and setProperty. How about clear this issue with AlterTableNode#clone? These methods worth to be refined.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right. All those methods need to be refined. But, IMO, they are all internal APIs, and don't have to be consistent. So, I think that the new method has a better signature.

@jihoonson
Copy link
Contributor

Hi @dongjinleekr, I looked over your patch. It looks good to me in overall. I left a single trivial comment.

tableMeta = tableDesc.getMeta();
assertEquals(tableMeta.getPropertySet().size(), 2);
assertNotNull(tableMeta.getProperty("timezone"));
assertNotNull(tableMeta.getProperty("text.null"));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should verify the unset property.

@dongjinleekr
Copy link
Contributor Author

dongjinleekr commented Jul 7, 2016

@jihoonson @jinossy Thanks for your comments. I applied all of them. (You can see the link to the comment in the log message of each commit.) Thanks for reviewing!

@dongjinleekr
Copy link
Contributor Author

As soon as you accept this pull request, I will request another one - the fix for the glitches discussed in this issue. I already completed that work. :)

@@ -43,6 +44,8 @@
private AlterTableOpType alterTableOpType;
@Expose @SerializedName("TableProperties")
private Map<String, String> params;
@Expose @SerializedName("TablePropertyKeys")
private List<String> propertyKeys;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be better to change this variable to be more intuitive as well. I think getter and setter also need to be changed together.

@jihoonson
Copy link
Contributor

@dongjinleekr thank you for the quick update! I left my last comment.
Thanks!

@jihoonson
Copy link
Contributor

+1. The latest patch looks good to me.
@dongjinleekr thank you for your contribution!

@asfgit asfgit closed this in fab36f9 Jul 11, 2016
@jinossy
Copy link
Member

jinossy commented Jul 11, 2016

+1
@dongjinleekr Thanks for your contribution!!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants