Hi On Wed, May 17, 2017 at 3:08 PM, Surinder Kumar < surinder.ku...@enterprisedb.com> wrote:
> Hi Dave, > > *Implementation:* > > 1) Took a flag 'is_row_copied' for each copied row: > > - to distinguish it from add/update row. > - to write code specific to copied row only as it requires different > logic than add row. > > 2) After pasting an existing row: > > - If a user clear the cell value, it must set cell to [default] value if > default value is explicitly given for column while creating table otherwise > [null]. > > - Again, if a user entered a value in same cell, then removes that value, > set it to [null] (the same behaviour is for add row). > > 3) Took a 2-dimensional array "grid.copied_rows" to keep track the changes > of each row's cell so that changes made to each cell are independent and > removed once data is saved. > > 4) On pasting a row, the cell must be highlighted with light green colour, > so triggers an addNewRow event. Now copied row will add to grid instead of > re-rendering all rows again. > > 5) Moved the common logic into functions. > > This patch pass the feature test cases and jasmine test case. > Also I will add the test cases for copy row and send an updated patch. > > Please find attached patch and review. > Looks good. I saw the following issues: - The "new" row is not available once I've created the first new row, or pasted some. - Rows are pasted in reverse order. - If I copy/paste a new row that has yet to be saved, none of the values are actually copied. - Attempting to save a row that contains all null/default values results in an invalid query: INSERT INTO public.defaults ( ) VALUES ( ); I think the only answer here is to explicitly insert NULL into any columns *without* a default value. Thanks. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
