db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Features - Quick or correct??
Date Fri, 10 Dec 2004 21:19:13 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In this case I think it is good that a quick implementation of intersect
and except has been submitted.  Especially with new standard features it
gives the community something to test that the feature is correct.  I
believe these features will allow more applications to ported over to
derby and thus give us more early feedback on what is important to do
next.  The earlier it
is submitted the more tests that can be submitted.

If it runs too slow then performance can be addressed.  Given that a
sort merge in memory is being used I don't expect it to be too slow. Of
course once checked in the community can compare it's performance with
other systems.  Encouraging iterative development also opens up the code
to the community earlier for testing and review.  I think this is better
than possibly sitting on a big prject without multiple checkpoint steps.
~ Of course each checkin should pass all tests, submit new tests for the
new feature and not present regressions to the rest of the code.  Again
iterative development is more acceptable now that the community has the
option of picking up the stable branch or the in flux development line.

Daniel John Debrunner wrote:
| RPost wrote:
|
|
|>>>Jack Klebanoff wrote:
|>>>
|>>>I wanted to make an initial implementation that is simple, handles both
|>>>INTERSECT and EXCEPT, and that fits into the current Derby
|>>>implementation fairly easily. If the performance of INTERSECT or EXCEPT
|>>>proves to be important then we should revisit this.
|>>>
|>>
|>>
|>>I certainly agree with this approach. The first priority is to get
|
| something
|
|>>that works
|>>as easily and simply as possible.
|
|
| I'm not completely convinced this is the correct approach. While it is
| good to have the functionality (and maybe more importantly the tests)
| quickly, first impressions count. So if we (the Derby community) produce
| correct but slow features, it will be hard to shake that image.
|
| Contributors & committers should be encouraged to discuss design ideas
| with the list early rather than once they have coded them up.
|
| It's also hard for me to tell with various contributions if the
| contributor thinks the feature is complete, or it's an incremental step
| to the fully completed feature. I think the incremental step is a great
| way to go, but only if it's identified as that, and the future steps are
| listed so the contributor or someone else can address them. Then it's
| also easy to discuss which of those steps are essential before a feature
| is considered ready for production release.
|
| Dan.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBuhLQEpeslyHqPs0RAnpIAKDe5JBZ49/IMfxrV69+DML3ZIFtQACcDGnP
vPFswuy+3X8OXT5Jxuj25A8=
=7x15
-----END PGP SIGNATURE-----

Mime
View raw message