> On Sept. 9, 2021, 1:18 p.m., Pradeep Agrawal wrote: > > Please propose changes only for the column you are facing the issue. > > Tsung-Ju Lii wrote: > My issue was that the `varchar(4000)`s in the code made deployment > impossible due to MySQL complaining about row size exceeding max table size. > > If there are actually columns that are supposed to have 4000 characters > then I'll change them back, but for now I don't really see why you'd need > 4000 characters for any of the columns. > > Madhan Neethiraj wrote: > Tsung-Ju Lii - which table(s) did MySQL compained about row size? > Reducing the size can break existing deployments having data longer than 256 > characters in modified columns. As Pradeep suggested, please minimize the > scope of this change to a small set of columns. Also, it is important to > verify that there is no data loss due to this patch, perhaps by using a Java > patch that scans the modified columns for data longer than the new limit. > > Tsung-Ju Lii wrote: > Hi Madhan, > > > which table(s) did MySQL compained about row size? > > This was from a while back so can't really remember which tables were > having the issue, but what happened was when I fixed a table that had this > issue (by changing `varchar(40000)` to `TEXT`) there would be another one > that had this issue, so I figured it's easier to just do `sed -i > 's/varchar(4000)/TEXT/g' ranger_core_db_mysql.sql`. > > > Reducing the size can break existing deployments > > Good point, I was doing a new deployment and totally forgot that part... > Then I guess it would be reasonable to provide a suggested setting for MySQL > configurations. Pretty sure if it's a brand new MySQL database it won't work > right out of the box alongside Ranger. > > > it is important to verify that there is no data loss due to this patch, > perhaps by using a Java patch that scans the modified columns for data longer > than the new limit. > > No idea how to do that...
you can check the length of the string in java code and decide whether that much length should be allowed or not. Also if you feel if column information is not important for future then you can think about trimming it. Usually we regularly visit the limitation of sql schema (datatype,size,column,keys,references) and modify it as per the requirement. Hence i requested to provide details about the column where you are facing the issue. Also you can consider the fix for sometime in your local branch and later propose the patch, i assume its not a blocker. - Pradeep ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/73564/#review223465 ----------------------------------------------------------- On Sept. 8, 2021, 6:57 p.m., Tsung-Ju Lii wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/73564/ > ----------------------------------------------------------- > > (Updated Sept. 8, 2021, 6:57 p.m.) > > > Review request for ranger. > > > Repository: ranger > > > Description > ------- > > The patch is just substituting all occurrences of `varchar(4000)` with > `varchar(256)` in `core_db.sql` files. > > > Diffs > ----- > > security-admin/db/mysql/optimized/current/ranger_core_db_mysql.sql > 8e925e5d7 > security-admin/db/oracle/optimized/current/ranger_core_db_oracle.sql > 638d9fbf2 > security-admin/db/postgres/optimized/current/ranger_core_db_postgres.sql > 500e83f01 > > security-admin/db/sqlanywhere/optimized/current/ranger_core_db_sqlanywhere.sql > 0048e504c > > > Diff: https://reviews.apache.org/r/73564/diff/2/ > > > Testing > ------- > > After I applied this patch I was able to deploy using MySQL. Without it the > deploy would fail. > > > Thanks, > > Tsung-Ju Lii > >
