You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Andreas Korneliussen <An...@Sun.COM> on 2006/03/28 10:54:59 UTC
Re: SUR plan 2
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.
>
>
>
> ------------------------------------------------------------------------
>
>
Re: SUR plan 2
Posted by Andreas Korneliussen <An...@Sun.COM>.
Andreas Korneliussen wrote:
> Er dette den nyeste planen ?
>
Oops, this was just an outdated plan for the SUR features, did not
intend to send it to the derby-dev list :-(
Andreas