db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satheesh Bandaram <sathe...@Sourcery.Org>
Subject Re: Planning for a 10.1 release
Date Mon, 23 May 2005 19:11:22 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Actually 'retrieveMessageText' property would only apply to Derby
client. So is '<b>securityMechanism</b>' and tracing properties.
Embedded driver doesn't have the tracing mechanism that is part of
Derby client.<br>
<br>
I would like to see a complete proposal that passes all tests as soon
as possible. I am worried the devil may be in the details ...<span
 class="moz-smiley-s1"><span> :-) </span></span><br>
<br>
Satheesh<br>
<br>
Jeremy Boynes wrote:<br>
<blockquote cite="mid42914FA4.5010405@apache.org" type="cite">Daniel
John Debrunner wrote:
  <br>
  <blockquote type="cite">
    <blockquote type="cite">Early implementation is one thing, but you
want to get the public
      <br>
interfaces right, or at least easily extensible, from the start so you
      <br>
don't end up regretting something forever.
      <br>
    </blockquote>
    <br>
    <br>
True, but in this case the public api is defined by class name(s) (that
    <br>
implements DataSource) and a set of JeavBean properties, and what those
    <br>
properties mean and how they interact with each other.
    <br>
    <br>
Thus we should not have a Java code strawman but instead a table of
    <br>
properties, like table 9.1 in section 9.4 in JDBC 3.0 spec.
    <br>
Though in the unified case the table would need additional columns to
    <br>
indicate what they mean in each mode, emebedded, client etc.
    <br>
    <br>
I think that would be the best way to look at this, see how many
    <br>
properties are common to each mode, how many could confuse users, e.g.
    <br>
portNumber for embeddded (especially when running embedded with an
    <br>
embedded network server). How complicated any rules are. etc.
    <br>
    <br>
Property overload for the user is what I'm concerned about.
    <br>
    <br>
  </blockquote>
  <br>
I JavaDoc'ed the properties in the code including a description of how
they interact (to my knowledge at least). It seems fairly logical to me
now.
  <br>
  <br>
I made the ConnectionFactory impl pluggable by the user with a default
impl that chooses embedded or client based on whether serverName is set
or not. I think the only redundant property is portNumber.
  <br>
  <br>
It does not yet support the client tracing options - I held off on that
because if we are going to unify we should support it in both client
and embedded modes and I don't think embedded has that (or if it does
it is set up differently).
  <br>
  <br>
Similarly with things like message text, database password, encryption,
result set holdability and so forth - they should work the same
regardless of whether the server in embedded or remote.
  <br>
  <br>
I still need to do the unified Driver impl - ran out of time this
weekend but may be able to get to it tomorrow (I have all day in a tin
can).
  <br>
  <br>
I also ran into what appear a couple of quirks in the client but will
move those to a separate thread.
  <br>
  <br>
--
  <br>
Jeremy
  <br>
  <br>
  <br>
  <br>
</blockquote>
</body>
</html>


Mime
View raw message