Database I-Team Meeting - August 19, 2008

Attendees: David Van Couvering, Roman Mostyka, Jayashri Visvanathan, Andrei Badea, John Baker, Rob Englander, and James Branam


  • Bug status
  • Discuss incoming/outgoing bug rate and changing our estimates for FCS
  • Discussions of how we do unit testing with a live database
  • Discussion around handling exceptions from the database
  • Proposal for setting up a Hudson build that does db unit tests
  • Discussion of strategy for DB tooling moving forward

David: Bug status: 131 P3s, about the same as last week. No P1s and 4 P2s. I own 3 P2s. We need to discuss the testing one, Andrei. Roman sent out a link showing our bug rate.

Jayashri: Code freeze for FCS is September 15. Maybe can assume 1 bug/day like in the past. ! P3 bug per person per day. We have four weeks. This would solve 60-80 bugs. If we can predict the incoming rate, then we can set a number.

David: The incoming rate isn't consistent. Just last week, we had 30 bugs files, the week before 20, the week before 15. I guess the average would be about 30 per week.

Rob: Does this rate correspond to milestones? It might help to know this.

David: It looks like this might be the case. I think 30 is a good average, ignoring the big spikes.

Jayashri: I think we can assume 25-30.

David: Our fix rate is and has been higher than the incoming rate.

Jayashri: I'll calculate a number and send it to the alias.

David: There's a P2 open: testing. SQL Executor. Is it OK to have Derby in the code line? It's make the code size bigger.

Jayashri: This is just for testing? I think what's convenient is good. I don't think that the size is too big.

David: The team were cleaning out external dependencies, and it came up. It was about 6 months ago.

Andrei: My recollection is that there were two Derby versions in the repository. The goal was to get rid of one of the distributions.

David: Then we get rid of the other derby.jar?

Andrei: I'm not so sure about that now. We'll see if they can use it in the embedded mode. If so, then we can get rid of the other jar. We need to remove the .zip and keep the .jar.

David: I'm configure my tests to use derby.jar. We could make ait a P3 defect and track it that way.

Andrei: This could affect runoff unit test we have set up on Hudson.

David: The only ones that require external configuration are the newer ones, and I can move those over.

John: what abotu testing otehr databases?

David: there are wa couple of things II need to test against MySQL?

John: Why can't we run unit tests against externally-installed databases.

David: This would be way too much work.

Andrei: I had a similar problem with metadata model tests. I had a single MySQL-specific test case. We should test something on a specific databases, and we'll need to have a server somewhere. Most code is generic and runs on all database. Most unit tests are run against the Derby database.

David: What about making MySQL the default?

Jayashri: We should be giving more attention to MySQL.

Roman: I'll determine the configuration for the default database.

David: The tests do wun if you have MySQL configured.

Andrei; I still believe that most unit tests should run out of the box without an external server. MySQL is the product that we should test on. We have a test distribution that is downloadable and users can run these tests. The unit test should run on Derby by default, and those on Hudson should run on MySQL.

David: The test class looks for server properties. Each module gets its own configuration. I'll follow up on this. As Sun developers, we should be running our tests on MySQL.

David; Handling exceptions. The are a number of issues that report getting exceptions. I'd like some clarity as to when we should report an exception or bring up a dialog. We can have a dialog for all exceptions. Are there any special cases?

Andrei: we should try to avoid the unexpected exception.

John: The SQL exceptions should ...<missed - fading out>

David: we want to avoid exceptions print stacktrace.

Andrei: I agree. Also, we shouldn't have a lot of specific exception classes. Exception classes should only be created when necessary.

David: We don't need unhelpful error reporting. I have a bug now where a user caught an exception. There's a huge amount of code. You have to include the exception in your constructor.

Rob: OK, summarizing. If you try to establish a new connection to a MySQL server and you enter the wrong port, you get a connection refused. Some things that aren't exceptions are thrown as exceptions.

David: the only thing we can do is say that "this is likely caused by ..." Solaris error message policy dictates that we should include the likely cause and the best way to fix it.

Andrei: Then we might end up with a lot of generic messages.

David: If you don't know what the cause is, there is no point in saying, "the cause could be pretty much anything..."

David: Database tooling strategy. I've given a draft to Jayashri. I'll bring it to the team next week.

Rob: Nothing to report. I'm getting back into the swing of things, focusing on UI things.

Roman: Nothing from me.

John: I have something for offline. The history action is being whitelisted. I've gone through my P3s and I think I can fix them for 6.5.

Andrei: If you could open # 73341: Need ability to parse multiple arbitrary statements without standard separator. This works when the statements are not separated by semicolons. I don't know why we should send statements to be parsed one-by-one when we can do it all at once in DataView.

David: I thought that of it couldn't be parsed, then it would show up as read only. I'll jump in on this dialog. The user wants it to be sent as a single execute statement.

Andrei: I don't think the user cares. I just think it's something that we should not be doing.

David: we're not going to parse this.

John: I agree.

Andrei: I might turn this into an enhancement.

David: Jayashri, I'm looking forward to seeing the number you come up with.

Jayashri: I'll have something today.

James: Nothing from me today.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo