[ http://issues.apache.org/jira/browse/DERBY-289?page=all ]
Rick Hillegas updated DERBY-289:
Fix Version/s: 10.3.0.0
(was: 10.2.2.0)
Move to 10.2.3.0.
Enable code sharing between Derby client and engine
[ http://issues.apache.org/jira/browse/DERBY-289?page=all ]
Rick Hillegas updated DERBY-289:
Er, make that 10.3.0.0.
Enable code sharing between Derby client and engine
---
Key: DERBY-289
[ http://issues.apache.org/jira/browse/DERBY-289?page=all ]
Rick Hillegas updated DERBY-289:
Fix Version/s: 10.2.2.0
(was: 10.2.1.0)
Moving to 10.2.2.0.
Enable code sharing between Derby client and engine
[ http://issues.apache.org/jira/browse/DERBY-289?page=all ]
Rick Hillegas updated DERBY-289:
Urgency: Low
Enable code sharing between Derby client and engine
---
Key: DERBY-289
David Van Couvering (JIRA) wrote:
Hi, all. Here is the proposed patch that provides the framework for code
sharing. I was thinking folks could look at it and discuss, and then once
issues have (hopefully) been worked out, we can have a vote.
Thanks for posting this patch. It helped me
Thanks, Kathey, some responses below
Kathey Marsden wrote:
David Van Couvering (JIRA) wrote:
Hi, all. Here is the proposed patch that provides the framework for code
sharing. I was thinking folks could look at it and discuss, and then once
issues have (hopefully) been worked out, we can
Here is a possible solution to the versioned message id problem:
o The message resolver needs two pieces of information from its callers:
1) the actual message ID, 2) the derby version that its caller was
compiled at.
o The names of built message files need to encode the derby version
number.
Rick Hillegas wrote:
Here is a possible solution to the versioned message id problem:
[snip details ...]
o The Derby build can create message files whose names contain the
current value of DERBY_VERSION.
[snip more details]...
If the derby build is going to create extra message files, why
Hi Kathey,
What you say is true if the classpath contains an embedded Derby app and
a client app. But I don't think it works if the classpath contains two
embedded Derby apps or two client apps (at different version levels). I
think that encoding a version number makes all cases work.
If
Rick Hillegas wrote:
Hi Kathey,
What you say is true if the classpath contains an embedded Derby app
and a client app. But I don't think it works if the classpath contains
two embedded Derby apps or two client apps (at different version
levels). I think that encoding a version number makes
I don't understand what you mean by distinguish client from server
messages. Client messages would be in client-messages.properties,
server messages are in m_*.properties. When the engine asks for a
message, it specifies the appropriate m_*.properties file based on
message id. When the
By the way, this solves the message versioning problem, but doesn't
solve the overall forward/backward compatibility issue and the code
cruft that it will engender.
In reading Kathey's email, I also seem to understand that there are
issues beyond code compatibility. In particular, we seem to
Hi Kathey,
Some comments follow. Cheers-Rick
Kathey Marsden wrote:
...
You can't have two client apps at different version levels in the same
classloader. The one loaded first will win.
I'm not so sure this is true. If classes are added/deleted to/from the
public API, then it may
I think having 2 embedded Derby or 2 client derby apps at different
version levels in the same JVM is wrong. It is technically feasible but
is it rational? Separate classloaders should be used if one intends to
run 2 different versions of embedded derby in the same JVM. Actually,
of one of the
Perhaps we could impose the following rules and enforce the first with a
lint tool, either at release time or as part of a comprehensive weekly test:
1) If you change the number of args in a message, then you need to
create a new message id.
2) At the same time, you need to replace all
Great, thanks for your very great analysis, Deepa! I'll fix these bugs.
David
Deepa Remesh wrote:
On 11/15/05, David Van Couvering [EMAIL PROTECTED] wrote:
In the meantime, let's focus on the issue you encountered. It's funny,
the error isn't that the message id was not found. Instead,
I think the lint tool sounds great! That said, I don't get how it
solves the forward-compabitility code crud as Deepa's code exemplifies,
where you have to check for the feature id to make sure you can use the
new message id before.
David
Rick Hillegas wrote:
Perhaps we could impose the
Oh, right, I didn't track that one. Over time these versioned overloads
and if-blocks will calcify the code..
-Rick
David W. Van Couvering wrote:
I think the lint tool sounds great! That said, I don't get how it
solves the forward-compabitility code crud as Deepa's code
exemplifies, where
Another great verb from Rick that captures the situation perfectly... :)
David
Rick Hillegas wrote:
Oh, right, I didn't track that one. Over time these versioned overloads
and if-blocks will calcify the code..
-Rick
David W. Van Couvering wrote:
I think the lint tool sounds great! That
David W. Van Couvering wrote:
Hi, Dan, I get it now. Yes, I think this is feasible, and I'll work on
that. The network client code could do something like
throw ExceptionUtil.newSQLException(SQLState.ERRCODE, arg1, arg2);
Meanwhile, your inspection of and comments on the rest of the
Hi David,
I applied the patch for DERBY-289 and tried a use case which adds a
new parameter to an existing message. I did the following:
Step 1:
First, I tried moving a message (07000) from
org.apache.derby.loc.messages_en.properties to
org.apache.derby.loc.common-messages_en.properties. I moved
Hi, Dan, thanks much for your review. My responses below...
Daniel John Debrunner wrote:
David W. Van Couvering wrote:
Hi, Dan, I get it now. Yes, I think this is feasible, and I'll work on
that. The network client code could do something like
throw
Deepa Remesh wrote:
I changed client driver to use the new message:
if (!parameterSet_[i] !parameterRegistered_[i]) {
CommonInfo cInfo = new CommonInfo();
if(cInfo.hasFeature(CommonFeatures.SQLSTATE_07000_NEW))
Hi, Deepa, thanks for doing this test. I am going to think about Dan's
suggestions for simplifying the code for message ids, and will respond
directly to his email.
In the meantime, let's focus on the issue you encountered. It's funny,
the error isn't that the message id was not found.
Hi, Dan. I was taken off guard by the incompatibility of message
changes, too. However, note that you will have to do something similar
every time you add a new parameter to a method, and it's likely that
over time our code will be littered with conditional logic like this.
Your suggested
On 11/15/05, David Van Couvering [EMAIL PROTECTED] wrote:
In the meantime, let's focus on the issue you encountered. It's funny,
the error isn't that the message id was not found. Instead, we weren't
able to find org.apache.derby.loc.client-messages.properties.
I think this is because the
David Van Couvering (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-289?page=all ]
David Van Couvering updated DERBY-289:
--
Attachment: DERBY-289.diff
Hi, all. Here is the proposed patch that provides the framework for code
Hi, Dan, I get it now. Yes, I think this is feasible, and I'll work on
that. The network client code could do something like
throw ExceptionUtil.newSQLException(SQLState.ERRCODE, arg1, arg2);
Meanwhile, your inspection of and comments on the rest of the patch
would be much appreciated!
[ http://issues.apache.org/jira/browse/DERBY-289?page=all ]
David Van Couvering updated DERBY-289:
--
Attachment: DERBY-289.diff
Hi, all. Here is the proposed patch that provides the framework for code
sharing. I was thinking folks could look at
David Van Couvering (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-289?page=all ]
David Van Couvering updated DERBY-289:
--
Attachment: DERBY-289.diff
Hi, all. Here is the proposed patch that provides the framework for code
sharing. I
[ http://issues.apache.org/jira/browse/DERBY-289?page=all ]
David Van Couvering updated DERBY-289:
--
Comment: was deleted
Enable code sharing between Derby client and engine
---
Key:
[ http://issues.apache.org/jira/browse/DERBY-289?page=all ]
David Van Couvering updated DERBY-289:
--
Comment: was deleted
Enable code sharing between Derby client and engine
---
Key:
32 matches
Mail list logo
