[
https://issues.apache.org/jira/browse/HDDS-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16592163#comment-16592163
]
Anu Engineer commented on HDDS-359:
-----------------------------------
[~xyao] Thanks for the review. The next patch addresses some of the comments.
{quote}DBConfigFromFile.java Line 122: can we move this to line 117 so that the
caller does not need to check null.
{quote}
Here is what we are doing, if there is a name.db.ini in the config directory,
we will use those params for the RocksDB. Otherwise we will use the profile key
if specified, if there is nothing specified we will use the default profile.
The return of null makes it easy for us to know that we need to get profile
from the secondary sources.
{quote}Line 79: NIT: annotate for test only?
{quote}
addTable is not test only, if you add a table without columnfamily, we will
default to profiles.
{quote}Line 118: NIT: rename from processTableNames => processTables?
{quote}
Done.
{quote}Line 141: this assumes all tables have the same column family option. Is
it possible to have per table column family option
{quote}
We already do that. When the user add a table, they can call addTable(string)
or addTable(string, options). If the first addTable is used, we iterate thru
the string table and add the default option. If the user had called
addTable(string, option) then the user specified option would be used.
{quote}Line 144: should we document in the build class that addTable() should
not add
{quote}
I can do that, but if the user tried to add an existing table we will throw an
exception. we have a test case for that case.
{quote}Line 148-170: the current code loads from rocksDBOption parameter, OR
config file OR pre-defined db profiles? Is it possible to allow all of these
and merge/overwrite with the config file like hadoop configs.
{quote}
The current code attempts to get config in a heireachical fashion.
First it looks for the config from an .INI file, if not found, it will try to
read the profile from ozone-deafult.xml and if that is not defined, we will use
the default profile. We don't try to merge the configs, but use each one. It is
hard to merge these since it because harder to define what the final config
will look like.
{quote}Can we abstract the table config otherwise we can use
ColumnFamilyOptions directly
{quote}
Sorry, I am not sure I understand this comment clearly. Could you please
explain it to me once more ?
{quote}Test.db.ini : Add an exception to the license check plugin?
{quote}
done.
{quote}Line 67: should we clean up the copied test ini file in the tearDown?
{quote}
we are copying a file into the Temporary folder. Junit will clean it up
automatically at the exit of the test.
> RocksDB Profiles support
> ------------------------
>
> Key: HDDS-359
> URL: https://issues.apache.org/jira/browse/HDDS-359
> Project: Hadoop Distributed Data Store
> Issue Type: Bug
> Reporter: Xiaoyu Yao
> Assignee: Anu Engineer
> Priority: Major
> Fix For: 0.2.1
>
> Attachments: HDDS-359.001.patch, HDDS-359.002.patch,
> HDDS-359.003.patch, HDDS-359.004.patch
>
>
> This allows us to tune the OM/SCM DB for different machine configurations.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
