-----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-----
