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

Reply via email to