[MCOL-311] utility for finding objects file Created: 2016-09-23 Updated: 2023-10-26 Resolved: 2016-12-08 |
|
| Status: | Closed |
| Project: | MariaDB ColumnStore |
| Component/s: | None |
| Affects Version/s: | 1.0.3 |
| Fix Version/s: | 1.0.6 |
| Type: | New Feature | Priority: | Critical |
| Reporter: | David Thompson (Inactive) | Assignee: | David Hall (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Sprint: | 2016-21, 2016-22, 2016-23, 2016-24 |
| Description |
|
A utility should provide a means of determing the directory for the first file of a given object. This is useful for troubleshooting. Arguments:
|
| Comments |
| Comment by David Thompson (Inactive) [ 2016-10-25 ] |
|
This should be implemented as an mcsadmin function, e.g named findObjectFile. It should take the following set of arguments (either / or):
|
| Comment by David Hall (Inactive) [ 2016-11-14 ] |
|
For review |
| Comment by David Thompson (Inactive) [ 2016-11-24 ] |
|
Pull request was never merged.. |
| Comment by David Hill (Inactive) [ 2016-11-24 ] |
|
reviewed, all looks good |
| Comment by David Hill (Inactive) [ 2016-11-30 ] |
|
needs to be merged |
| Comment by Daniel Lee (Inactive) [ 2016-12-01 ] |
|
Build tested: nightly build targeted for 1.0.6 [root@localhost mariadb-columnstore-server]# git status
Merge pull request #18 from mariadb-corporation/ [root@localhost mariadb-columnstore-server]# cd mariadb-columnstore-engine/ Merge pull request #64 from mariadb-corporation/ ---------- 1) incorrect command name of "getDatafileName" is returned Current: mcsadmin> findobjectfile getDatafileName requires one of 2) When supplied with an table object ID, which is not associated with any data file, it still outputs an directory. "OID directory not found" is too alarming, suggesting that a directory is missing. Also "file name" should be "Path" or 'Directory name". Current: mcsadmin> findobjectfile 3004 Suggestion: OID=3004 Object=[schemaName.tableName] 3) When supplied with an invalid OID, it should indicate as such. Current: mcsadmin> findobjectfile 30050 Suggestion: 4) When column OID is supplied, we should return the object name as a confirmation for the user, since the OID itself is meaningless. Current: findobjectfile Thu Dec 1 21:51:18 2016 Suggestion: |
| Comment by David Hall (Inactive) [ 2016-12-06 ] |
|
Made the changes as requested by QA. There's a new pull request. |
| Comment by David Hill (Inactive) [ 2016-12-07 ] |
|
review looks good based on Daniels request... Testing, I asked this before so need to make sure what happens in the test phase. Does this command on a separate system when run on a um and a pm asking for the same info on a OID... |
| Comment by Daniel Lee (Inactive) [ 2016-12-07 ] |
|
Build verified: Github source Still having couple issues. 1) table object returned the first column of the table. mcsadmin> findobjectfile 3147 2) OID for dictionary column treated as invalid OID (3153 is the OID for n_comment dictionary) |
| Comment by Daniel Lee (Inactive) [ 2016-12-07 ] |
|
Per my last comment, couple issues identified. |
| Comment by David Hall (Inactive) [ 2016-12-07 ] |
|
I opened The complaint about table oids returning the first column file name. This is intentional (though not documented). What behavior should it be for a table oid? There are no data files associated with a table, only with columns. |
| Comment by David Hall (Inactive) [ 2016-12-08 ] |
|
Added the concept of reporting for all columns when table name or table oid are entered to |
| Comment by David Hall (Inactive) [ 2016-12-08 ] |
|
The concerns of QA are addressed in |
| Comment by Daniel Lee (Inactive) [ 2016-12-08 ] |
|
I suggest to output a message stating that the supplied OID is for the table object and not to output a path since there is none. It is not good to return something else when the requested info is not found. That makes the result unpredictable and hard for user to script to account for that. |