db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Korneliussen <Andreas.Kornelius...@Sun.COM>
Subject Re: SUR plan 2
Date Tue, 28 Mar 2006 08:54:59 GMT
Er dette den nyeste planen ?

Andreas
Dag H. Wanvik wrote:
> * Enact id: 88: FEA-1 Scrollable updatable result sets - items & estimates for
>                 remaining work pr 2006-01-15
> 
> Completed subtasks are omitted.  For tasks given, all estimates are
> for remaining work pr 2006-01-15, not total!
> 
> All effort number include "normal overhead", i.e. expresses how
> long it would a person on full time to complete the task, given
> normal department activities such as weekly meetings etc.
> 
> Enact id 100 "rewrite existing tests" has been cancelled, resources
> have not been allocated (Geir's decision).
> 
> Allocation and scheduling is done separately in the spreadsheet
> accompanying this task description.
> 
> 
> Subtasks of 88 (no indentation)
> 
> * Enact id: 89: Design doc
> Remaining: 2-3 w
> 
> The documents is available, but has not been posted to the
> community yet. It needs some brushing up:
>     - a section on client server design to support
>       detectability (DRDA changes)
>       Awaits community feedback now.
>     - note on re-reading of row iff table has one or more
>       indexes to be able to safely update index entries
>     - section on testing: what new tests have been added
>       and how they complement existing tests, so reviewers
>       can evaluate our total coverage.
>     - internal review
> 
> Finalization depends on 94 and 96.
> 
> * Enact id: 90: Derby-100 Insert FO-UR (forward only - updatable result set):
> Remaining: 1-2 w
> 
> Patch has been posted, positive comments have received, small
> changes need to be done to comply with comments
> 
> 
> * Enact id: 96: DERBY-775 client/server SUR
> 
> Subtasks of 96 (indented):
> 
>         * Enact id: x01 (new) Basic client code for SUR (without detectability)
>         Remaining: 2w
> 
>         Review and refactor parts of working prototype code. Separate
>         patch from 95.
> 
>         * Enact id: x02 (new) Detectability for client
>         Remaining: 3 w
> 
>         Works now without detectability implemented, remaining work is
>         to implement that. Detectability could be a separate patch.
>         Depends on tasks x01 and 95.
> 
>         * Enact id: x03 (new) Metadata
>         Remaining: 1w
> 
>         Change answers from database metadata methods as to driver
>         capabilities.
>         Same patch as x01.
> 
> 
> * Enact id: 94: DERBY-690 SUR embedded
> 
> Subtasks of 94 (indented):
> 
>         * Enact id: 95: Basic code for SUR (without holdability)
>         Remaining: 4w
> 
>         Review and possibly rework parts of working prototype code.
>         x01 and 95 will be separate patches.
> 
>         * Enact id: y01 (new) Metadata
>         Remaining: 1w
> 
>         Change answers from database metadata methods as to driver
>         capabilities.
>         Same patch as 95.
> 
>         * Enact id: 99: New tests for SUR
>         Remaining: 3w
> 
>         Many new tests have been written, we will most likely add some
>         more, when we review it.
>         We also need to review tests for coverage, including existing
>         FO-UR tests. We also need to run tests on client driver more
>         (Andreas has done embedded mostly so far).
>         Checklist:  navigation + updating + positioned updates
>                                + deleting + positioned deletes
>                                + inserts
>                     conflicts/concurrency
>                     detectability
>                     metadata
>                     holdability
> 
>         * Enact id: y02 (new) Convert new tests (JUnit based) to run in
>                     existing framework
>         Remaining: 1-2w
> 
>         This depends on enact id 99.
> 
> 
>         * Enact id: 97: Holdable cursors
>         Remaining: 2-3 w
> 
>         The issue here is that for rowPosition to remain valid after a
>         transaction commits, we need to retain the intentional lock on
>         the table so a compress cannot be executed before the result
>         set is closed. A compress would make the rowPosition exposed
>         to reuse. This could be a separate patch.
> 
>         Depends on 95.
> 
> * Enact id: z01 (new) Derby documentation update
> Remaining: 2-3w
> 
> Since JDBC allows much variation, we need to explain how insensitive,
> scrollable updatable works works in Derby. The specification is input
> to this work.
> 
> 
> * Enact id: 101: Missing client type conversions
> Remaining: 3w
> 
> updateString on SMALLINT, INTEGER, BIGINT, DECIMAL datatypes
> updateBytes on CHAR, VARCHAR, LONG VARCHAR datatypes
> updateTime on TIMESTAMP datatypes
> updateObject with null values
> 
> This is a low priority item. Will do (some of) it if time.
> Depends on 94 and 96.
> 
> 
> * Enact id: 102: Client updateClob/Blob
> Remaining: 3w
> 
> This is a low priority item. Will do (some of) it if time.
> Depends on 94 and 96.
> 
> * Enact id z02 (new) DERBY-787
> Remaining: 1w
> This is a low priority item. Will do it if time.
> 
> 
> ----------------------------------------------------------------------
> Comments:
> 
> Effort summary:
> 
> Remaining: 2-3 w
> Remaining: 1-2 w
> Remaining: 2w
> Remaining: 3 w
> Remaining: 1w
> Remaining: 4w
> Remaining: 1w
> Remaining: 3w
> Remaining: 1-2w
> Remaining: 2-3 w
> Remaining: 2-3w
> Remaining: 3w
> Remaining: 3w
> Remaining: 1w
> 
> Upper sum: 34w, divided by 3 people gives 11.3 weeks per person
> Lower sum: 29w, divided by 3 people gives 9.7 weeks per person
> 
> Available:
> 
>         January:  2 weeks * 2 (Andreas vacation) = 4
>         February: 4 weeks * 3                    = 12
>         March     4 weeks * 3                    = 12
>         April:    3 weeks * 3 (1 week easter)    = 9
>         ----------------------------------------------
>         Total available before ultimo april:       37w
> 
> 
> Risks:
> 
> Worst case estimates numbers leave 3 weeks (37-34) as a buffer.  A
> further buffer exists in the 7 weeks which are low priority tasks
> (101, 102 and z02).
> 
> It is somewhat hard to estimate the review cycles in the community
> ahead of time. Estimates try to include "normal" review times, but
> effort is one thing, calendar time for review is often quite another,
> and we must expect delays before some tasks are really committed. The
> community also wants more, smaller patches (increments) to ease
> review, adding to time spent in such cycles.
> 
> Task x02 (client detectability) could also be sacrifized in a pinch;
> we do not know that creator needs this, but it would be a "wart" to
> leave it unfinished. That could also cut 3 weeks off the
> schedule. Possibly the community might then want to remove
> detectability alltogether, to keep client and embedded modes alike.
> 
> Finally, this being substantial new code in a large code base, new to
> all developers, we must allows for a somewhat larger uncertainty in
> estimates than usual. The estimates represents best guesses at this
> time in the project.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 


Mime
View raw message