Hi Dave, Please review the updated patch.
On Wed, May 17, 2017 at 8:46 PM, Dave Page <dp...@pgadmin.org> wrote: > 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. > Fixed. > > - Rows are pasted in reverse order. > Fixed. > > - If I copy/paste a new row that has yet to be saved, none of the values > are actually copied. > Fixed. > > - 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. > I could not reproduce, However #3 might have fixed it too. Apart from this, I noticed epicRandomString(...) function doesn't generate unique number always, due to this save and delete rows was affected. Not all rows saved or deleted. The new function always returns a unique random number. Fixed. > > Thanks. > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
RM_2400_v1.patch
Description: Binary data
-- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
