----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/55712/#review162386 -----------------------------------------------------------
I see we are creating map<storage_name, <update_period, storage_table>> in some places and I see map<update_peirod_storage_name, storage_table> in some places. I feel it can degrade code readability; and whenever storage names have to be pulled, we need to understand where is actual storage names vs modified storage names. Can we be consistent in creating storage name as actual storage name alone, no other storage names - and move all the prefixing to final place of physical table name creation. - Amareshwari Sriramadasu On Jan. 19, 2017, 12:08 p.m., Lavkesh Lahngir wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/55712/ > ----------------------------------------------------------- > > (Updated Jan. 19, 2017, 12:08 p.m.) > > > Review request for lens. > > > Bugs: LENS-1386 > https://issues.apache.org/jira/browse/LENS-1386 > > > Repository: lens > > > Description > ------- > > A new data structure XUpdatePeriodTableDescriptor is introduced which > contains an update period and table descriptor. Now the XUpdatePeriods will > contain a list of XUpdatePeriodTableDescriptor or XUpdatePeriod > > > Diffs > ----- > > lens-api/src/main/resources/cube-0.1.xsd f438f48 > lens-cube/src/main/java/org/apache/lens/cube/metadata/CubeFactTable.java > adb6c92 > > lens-cube/src/main/java/org/apache/lens/cube/metadata/CubeMetastoreClient.java > 6c9cde2 > lens-cube/src/main/java/org/apache/lens/cube/metadata/MetastoreUtil.java > 53cf8af > > lens-server/src/main/java/org/apache/lens/server/metastore/CubeMetastoreServiceImpl.java > 8b10d1d > lens-server/src/main/java/org/apache/lens/server/metastore/JAXBUtils.java > 51fcb43 > > Diff: https://reviews.apache.org/r/55712/diff/ > > > Testing > ------- > > > Thanks, > > Lavkesh Lahngir > >
