[VOTE][RESULT] Use svnpubsub for publishing DB project release artifacts
After 10 days, eight in favor, and no votes against, this vote passes. +1 votes were received from Craig, Greg, Michael, Thomas, Rick, Myrna, Camilla, and Dag. Next steps: The current Derby and Torque releases need to be copied to new svn directories under https://dist.apache.org/repos/dist/release/db/ This can be done by anyone in the DB PMC. Infra will then establish the sync to the official Apache release directory. Thanks, everyone. Craig On 24.03.14 18:11, Craig L Russell wrote: Hi PMC, Recently the JDO project set up to use svnpubsub to publish our releases. We have opened this JIRA to track the request: https://issues.apache.org/jira/browse/INFRA-7320 But because JDO is a sub-project of db, infra would like to have all or nothing for svnpubsub. This technique is easier and less error-prone than the alternative (manually copying release artifacts to dist/db via scp). The technique is described here: http://www.apache.org/dev/release#upload-ci The impact on Derby is that as part of the migration, a Derby release manager (actually anyone with commit privs to derby) will have to copy the release artifacts to the source svnpubsub repository: https://dist.apache.org/repos/dist/release/db/derby Once this is done, infra will synchronize the release/db directory with Apache's official release directory which is automatically mirrored worldwide. The downloads page that chooses a mirror will continue to work exactly as before. There are no other changes to release artifact naming. To stop mirroring a Derby release, the appropriate directory under https://dist.apache.org/repos/dist/release/db/derby simply needs to be svn rm'd. The change will automatically propagate to mirrors. Please vote to adopt this new release process. Here's my +1 Craig L Russell Architect, Oracle http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@oracle.com P.S. A good JDO? O, Gasp!
Re: Most efficient way to get max row id?
Echoing what Mike Segal said earlier, Why do you want to know? You might be using the wrong tool for the job. Craig On Oct 19, 2008, at 1:52 PM, Amir Michail wrote: Hi, I was wondering what is the most efficient way to get the max automatically generated row id. select max(...) is slow. Amir -- http://chatbotgame.com http://numbrosia.com http://twitter.com/amichail Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: performance issue
For something that large, it's probably best to file a JIRA and upload the code as a patch. You can decide whether the uploaded code can be licensed under the Apache license (e.g. if you don't mind it becoming a test case) or not. Craig On Oct 19, 2008, at 3:17 AM, Jonas Ahlinder wrote: We would be willing to share the code. What would be the best way to do this ? Theres 869 lines of code, do i just paste it in a mail to the list ? From: Bryan Pendleton [EMAIL PROTECTED] Sent: Thursday, October 16, 2008 8:49 PM To: Derby Discussion Subject: Re: performance issue I have tried running more threads, and it does seem to give better performance, but the current state of the client doesnt really allow for reliable testresults. With autocommit on, and with the disk running 100% usage ( and quite a bit of wait queue at least on Linux ) do you think multiple threads will really help ? Yes. But, before changing your benchmark, it seems better to try to understand the results you are getting. Are you willing/able to share your benchmark with the community? thanks, bryan Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Saving XML into a database
Hi Jay,
I haven't tried this but it might be worth trying.
Use the setAsciiStream(column, InputStream) method of PreparedStatement.
What your code has to do is to figure out how to implement an
InputStream that will deliver the ascii version of your xml document
from memory. Not knowing what interface your xml dom objects support,
you might be able to write the dom as a stream to a
ByteArrayOutputStream, take the byte[] result and create a
ByteArrayInputStream and pass that to setAsciiStream.
Craig
On Aug 28, 2008, at 9:21 AM, Iwud H8u wrote:
Hi Valentin,
Thanks for suggesting this... I should have been more specific with my
initial question. I have in-memory XML DOM objects which need to be
saved
into a database... If I adopt your approach, I will need to save my
DOM
objects to a file before reading them in...
I am looking for a way to insert in memory XML DOM objects into the
database
because my code generates these xml objects programatically.
Any ideas on how to do this?
Valentin Cozma wrote:
jay _ wrote:
I've been struggling to find some decent examples of how to save XML
into a Derby database.
I've managed to figure out that XML needs to be serialised into a
different datatype before it can saved in Derby. I am using a CLOB.
However, I am not quite sure how exactly to get the data into the
XML
column.
My sample code looks like this
String expression = INSERT INTO XML_DATA (DOCUMENT ) +
VALUES (XMLPARSE( DOCUMENT CAST (? AS CLOB) PRESERVE
WHITESPACE));
try
{
PreparedStatement preparedStatement =
connection.prepareStatement(expression);
// update statement and execute
//Element ele = getHomeViewElement();
logger.debug(xmlDocument = +
xmlDocument.getDocument().toString());
preparedStatement.setString(1, xmlDocument.toString());
preparedStatement.executeUpdate();
} catch (SQLException e) {
logger.warn(e);
}
Using either the Element or the Document toString() methods result
in
an exception
java.sql.SQLException: Invalid XML DOCUMENT: Content is not
allowed in
prolog.
I am inserting xml as blob ( binary ) . works like a charm . example
follows .
-- write
public void addFileVersion(int idFile, String autor, String
comentarii, InputStream stream, int fileSize) throws SQLException {
addVersionToFile.setInt(1, idFile);
addVersionToFile.setString(2, autor);
addVersionToFile.setString(3, comentarii);
addVersionToFile.setBinaryStream(4, stream, fileSize);
addVersionToFile.execute();
}
-- read
public void saveFileVersionToDisk(int idFile, File location)
throws
SQLException, IOException {
InputStream result = null;
getFileVersion.setInt(1, idFile);
ResultSet rs = getFileVersion.executeQuery();
if(rs.next()) {
result = rs.getBinaryStream(bytes);
}
if(result != null) {
OutputStream of = new FileOutputStream(location);
FileUtils.copyFiles(result, of);
}
rs.close();
}
-- table
create table file_versions(
id int NOT NULL PRIMARY KEY GENERATED ALWAYS AS IDENTITY
(START
WITH 1, INCREMENT BY 1),
id_file int not null constraint FK_FILE_VERSIONS__files
references files(id) on delete cascade,
autor varchar(100) NOT NULL,
comentarii varchar(1000) NOT NULL,
bytes blob not null);
Can someone suggest what I am doing wrong here?
Cheers,
Jay
Be the filmmaker you always wanted to be—learn how to burn a DVD
with
Windows®. Make your smash hit
http://clk.atdmt.com/MRT/go/108588797/direct/01/
--
View this message in context:
http://www.nabble.com/Saving-XML-into-a-database-tp19149566p19204059.html
Sent from the Apache Derby Users mailing list archive at Nabble.com.
Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
Re: Problem with UNIQUE constraint
Hi Dmitri, It would help if you would show your DDL to define the table and a short program segment that would demonstrate the problem. I've not heard of such a problem. Craig On Aug 13, 2008, at 1:07 PM, Dmitri Pissarenko wrote: Hello! I have a database table with a UNIQUE constraint. However, when I try to insert duplicate records, this happens without an exception (I'm using prepared statements). How can fix this problem, i. e. how can I achive that an exception is thrown, when my program attempts to insert a duplicate record in this table? Thanks in advance Dmitri Pissarenko Craig L Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Problem with UNIQUE constraint
The two Timestamp columns have resolution of nanoseconds, which you
might not see depending on how you format the columns.
Can you show two rows that have duplicate values?
Thanks,
Craig
On Aug 13, 2008, at 2:30 PM, Dmitri Pissarenko wrote:
Hello!
Thanks for your answer!
It would help if you would show your DDL to define the table
Create table MyTable
(
MyTableId BIGINT GENERATED ALWAYS AS IDENTITY,
field01 Varchar(40) NOT NULL,
field02 Timestamp NOT NULL,
field03 Timestamp NOT NULL,
field04 Varchar(40) NOT NULL,
field05 Varchar(40) NOT NULL,
field06 Time NOT NULL,
field07 Time NOT NULL,
field08 Varchar(40) NOT NULL,
field09 Varchar(40) NOT NULL,
field10 Varchar(40) NOT NULL,
field11 Varchar(4) NOT NULL,
field12 Varchar(3) NOT NULL,
field13 Varchar(4) NOT NULL,
field14 Integer NOT NULL,
field15 Varchar(3) NOT NULL,
field16 Varchar(40) NOT NULL,
field17 Varchar(40) NOT NULL,
field18 Varchar(40) NOT NULL,
field19 Integer NOT NULL,
field20 Integer NOT NULL,
field21 Integer NOT NULL,
field22 Integer NOT NULL,
field23 Integer,
field24 Integer,
field25 Integer,
field26 Integer,
field27 Integer,
field28 Integer,
field29 Integer,
field30 Integer DEFAULT -1,
CONSTRAINT MyTablePk PRIMARY KEY(MyTableId),
CONSTRAINT MyTableUnique UNIQUE (field02, field01, field03, field04,
field05, field06, field07, field08, field09,
field10, field11, field12, field13, field14, field15, field16,
field17, field18,
field19, field20, field21, field22)
);
CREATE INDEX MyTable_field02
ON MyTable(field02);
CREATE INDEX MyTable_field30
ON MyTable(field30);
and a short
program segment that would demonstrate the problem.
PreparedStatement statement = null;
try
{
statement = aConnection.prepareStatement(
MyTable.INSERT_STATEMENT);
statement.setString(1, someText);
statement.setTimestamp(2, getTimeStamp());
// ...
statement.execute();
}
catch (SQLException exception)
{
LOGGER.error(, exception);
}
finally
{
DatabaseUtils.closeIfNotNull(statement);
}
If I insert duplicate records with this code, no exception is thrown
for this particular table.
I have other tables, too, with UNIQUE constraint and there the
constraint works properly, i. e. when an attempt is made to insert a
duplicate record, an exception is thrown.
I appreciate any help about how to solve this problem.
Thanks in advance
Dmitri Pissarenko
--
http://www.xing.com/profile/Dmitri_Pissarenko
Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
Re: Determine which child table a record belongs to
This is a very common pattern in object-relational mapping. The column that contains the type of crane is commonly referred to as a discriminator column, and is commonly a CHAR, VARCHAR, or NUMERIC type. The value of the discriminator column that identifies which table to look for is referred to as a discriminator value. The alternative is to include all possible tables in a query, which is performance-limiting. Craig On Jan 29, 2008, at 10:16 AM, MZ_TRICSTA wrote: Oh! I see. So I would need to add a Type column for all my parent tables. That would definitely make things easier, but I was hoping there was some SQL code that would magically give me the name of the child table. Still, this will work fine. Thanks for all your help. ~Tricsta Brad Moore wrote: No problem. Glad to be of help. If you have a CraneType column in the master table then you could use that to determine which other table has associated data for that Crane. i.e. if CraneType = ROUGHTERRAIN then look in the RoughTerrainCrane table. Brad -- View this message in context: http://www.nabble.com/Determine-which-child-table-a-record-belongs-to-tp15164998p15165775.html Sent from the Apache Derby Users mailing list archive at Nabble.com. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Determine which child table a record belongs to
On Jan 29, 2008, at 10:49 AM, MZ_TRICSTA wrote: One last question, guys. What if there is overlapping between the child tables, so that one instance has more than one Type? Then you might want to model this as an Entity-Role relationship which allows multiple rows in associated tables for the same row in the primary table. If this is the case, then you can't use a single-valued discriminator. You could use a bit field represented as a number in which each bit corresponds to an associated Role with data in another table. Craig Craig L Russell wrote: This is a very common pattern in object-relational mapping. The column that contains the type of crane is commonly referred to as a discriminator column, and is commonly a CHAR, VARCHAR, or NUMERIC type. The value of the discriminator column that identifies which table to look for is referred to as a discriminator value. The alternative is to include all possible tables in a query, which is performance-limiting. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! -- View this message in context: http://www.nabble.com/Determine-which-child-table-a-record-belongs-to-tp15164998p15166419.html Sent from the Apache Derby Users mailing list archive at Nabble.com. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Getting Constraints 'SQL071017145943950' and 'SQL071017145906390' have the same set of columns, which is not allowed. while adding a Unique/primary key constraint to the table
Hi Suman, You do not get any extra value from II or IV. It's sufficient to have the primary key on the two columns. That gives you uniqueness for the columns and so an extra uniqueness constraint is redundant, and, well, erroneous. Craig On Oct 17, 2007, at 3:46 AM, Suman N wrote: Hi, I have executed the following queries on a table in the given order and I am getting the error mentioned below. I have created a table and then created an unique index on two columns for the table. I have used the same two columns to add a primary key for the table and then used a query to set the two columns with unique key constraint. I. CREATE TABLE XSLTEMPLATE_TEMP(TEMPLATEID BIGINT not null, LOCALEIDENTIFIER CHARACTER(5) not null, TEMPLATENAME CHARACTER(100), LATESTVERSION INT not null, CHECKEDOUT CHARACTER(1) not null, CHECKEDOUTBY CHARACTER(30), CHECKEDOUTVERSION INT not null, CHECKEDOUTTIME TIMESTAMP, COCOMMENT VARCHAR(300), TEMPLATEFILE VARCHAR(300), TEMPLATETYPE CHARACTER (10), TEMPLATEIDCODE CHARACTER(10), EDITABLE CHARACTER(1) not null, RELATESTO CHARACTER(10), LASTWRITTEN TIMESTAMP); II. CREATE UNIQUE INDEX XSLTEMPLATE_TEMP ON XSLTEMPLATE_TEMP(TEMPLATEID, LOCALEIDENTIFIER); III. ALTER TABLE XSLTEMPLATE_TEMP ADD CONSTRAINT XSLTEMPLATE_TEMP PRIMARY KEY(TEMPLATEID, LOCALEIDENTIFIER); IV. ALTER TABLE XSLTEMPLATE_TEMP ADD UNIQUE (LOCALEIDENTIFIER, TEMPLATEID); When the last query to add a unique key constraint on the table, I am getting the following error ERROR 42Z93: Constraints 'SQL071017145943950' and 'SQL071017145906390' have the same set of columns, which is not allowed. Either of the query iii or query iv alone could be executed successfully. I was not able to execute both these queries Can anyone please explain why I am getting this error and also suggest what needs to be done to avoid this error? Thanks Regards, Suman.N The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. If you are not the intended addressee please contact the sender and dispose of this e-mail. Thank you. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: checking if table exists
On Oct 3, 2007, at 6:44 AM, Bryan Pendleton wrote:
while((result.next()) (tableExists = false)) {
Is this possibly a typo? Make sure it says:
while((result.next()) (tableExists == false)) {
You want to do a logical and, not a bitwise and;
The difference between boolean1 boolean2 is not bitwise versus
logical; it's between unconditional versus conditional
operation. In this case, either or works fine since there are no
side effects of the assignment of false to tableExists.
also you want to do a comparison, not an assignment.
This I agree with.
Regards,
Craig
thanks,
bryan
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
Re: Why do class names start with lower lowercase?
Hi Sha Jiang, These are utility programs for which the natural name is lower case. For each class, there is a corresponding command, and rather than try to map dblook to a class DBLook or Dblook, the natural thing is to simply have the class name the same as the command name. Craig On Sep 17, 2007, at 5:39 PM, jiangshachina wrote: Hi guys, This may a stupid question :-D According to Java coding convention, class name would start with uppercase, but several class names of Derby start with lowercase, e.g. ij, dblook, sysinfo. Certainly, that isn't an issue, I just be curious of the matter. Thanks! a cup of Java, cheers! Sha Jiang -- View this message in context: http://www.nabble.com/Why-do-class- names-start-with-lower-lowercase--tf4470901.html#a12747871 Sent from the Apache Derby Users mailing list archive at Nabble.com. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: How to restrict external connections
Hi Néstor Boscán, Yes, only one process at a time can access the Derby database files for any particular database. There's no inter-process mechanism to prevent corruption if multiple processes were to access the files. There is a mechanism to prevent multiple processes from accessing the database. Craig On Sep 10, 2007, at 10:51 PM, Néstor Boscán wrote: Hi Mamta thanks for the answer. So basically Derby will only be up in one JVM at a time. Correct? Regards, Néstor Boscán De: Mamta Satoor [mailto:[EMAIL PROTECTED] Enviado el: Tuesday, September 11, 2007 1:13 AM Para: Derby Discussion Asunto: Re: How to restrict external connections Néstor, If a tool like ij is started in a new JVM, then it will not be able to connect to an embedded database which has been started by a different JVM. HTH, Mamta On 9/10/07, Néstor Boscán [EMAIL PROTECTED] wrote: Hi Kristian Thanks for the answer. So this means that if I open the database using the EmbeddedDriver driver no one can access the database from an outside connection?. Includiing tools like ij? Regards, Néstor Boscán -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Enviado el: Monday, September 10, 2007 4:27 AM Para: Derby Discussion Asunto: Re: How to restrict external connections Néstor Boscán wrote: Hi Is there a way to restrict external connection to a Derby Database?. I only want the JVM to be able to connect to the Derby database and no other external processes. Hello, Unless I have misunderstood, sounds like you simply want to use Derby embedded. This is done by using org.apache.derby.jdbc.EmbeddedDriver and specifying the connection URL as 'jdbc:derby:myDatabase [;create=true;...]'. By default, no network server will be started and only the JVM is able to access the database. Note that 'myDatabase' can point to a database by using either a relative path (relative to derby.system.home , or current working directory if it is unset) or an absolute path. Did that answer you question, or do you have any further requirements? regards, -- Kristian Regards, Néstor Boscán Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Static SQl in Derby
If your application constructs SQL dynamically, it can be designed to exploit the compiled query aspects by following some guidelines: 1. Always use parameter markers when constructing your SQL statements. So instead of generating SQL like SELECT e.name, e.salary FROM EMPLOYEE e where e.name =\ Johnny\, generate SQL SELECT e.name, e.salary FROM EMPLOYEE e where e.name =? and save Johnny in a parameter list in your code. Later, pass the saved parameter to the prepared statement. 2. Always prepare your dynamically generated SQL statement. This is what allows the JDBC driver to compile the unique statements only once. Craig On Aug 3, 2007, at 10:39 AM, Bryan Pendleton wrote: With dynamic SQL, database access and authorization are determined at run time. The user of the application must have all required database privileges, and the database must determine the best way to access the required data at run time. However, with static SQL, access and authorization are determined at customization and bind time. I think Derby is somewhere in between these two. The SQL statements are parsed, compiled, and optimized at runtime, in a dynamic fashion. However, the database engine automatically maintains a cache of compiled statements, and a re-preparation of a SQL statement simply retrieves the already-compiled statement information from the cache for execution. So Derby achieves the flexibility and adaptability of the dynamic approach, but it also realizes substantial performance benefits by caching the results of the statement bind process and re-using them wherever possible. thanks, bryan Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Wanted: Working example of JDBC4 Annotations.
Hi Siegfried, This is a bit confusing. Sun decided to distribute Apache Derby and call it JavaDB. The bits you download from the JavaDB site and the bits you get already installed when you install Sun's Java SE 6 JDK and the bits you can download from the Apache Derby site are the same (modulo release levels and documentation). [Also, Sun will offer support for the JavaDB bits but not the Apache Derby bits.] more below. On Jul 17, 2007, at 8:52 AM, sieg wrote: Could you tell me more about javaDB? I did a google search and found http://developers.sun.com/javadb/ and I see a download button. Is it the same as the apache derby that I already downloaded and installed? yes. It also says Now in Java 6. Since I have java 6 installed, do I have it installed twice? yes. When I tried to figure out how to start the server process for Java DB (I figured there must be a server process unlike Microsoft Access) I clicked on the quick start link and discovered I'm back to apache derby which I already have installed (quite seperately from Java 6) and running. If you're happy with the Apache Derby installation then there is no need to install or use the JavaDB either from download or from Java SE 6 JDK. Regards, Craig I'm confused. Thanks, Siegfried -- View this message in context: http://www.nabble.com/Wanted%3A- Working-example-of-JDBC4-Annotations.-tf4097303.html#a11652174 Sent from the Apache Derby Users mailing list archive at Nabble.com. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: maxrows - what does it really mean?
Hi David, Generally the JDBC spec stays clear of discussing the client-server protocol. The behavior described by the JDBC method is the user-visible behavior. There are two roles involved in the behavior, which might be implemented by two different providers: the JDBC provider (client) and the database provider (server). The JDBC spec doesn't mandate whether the behavior is implemented by one provider or the other. Where the server does have the ability to constrain the results there might be a way for the client to tell the server of the constraint, via the client-server protocol. On May 11, 2007, at 3:29 PM, David Van Couvering wrote: The behavior I want is to say get 10 rows at a time, with the least amount of processing and network overhead wasted on rows that I am not interested in yet. What's the strategy for this? the setMaxRows() method for Statement says: Sets the limit for the maximum number of rows that any ResultSet object can contain to the given number. If the limit is exceeded, the excess rows are silently dropped. What I am wondering is, is there any way to tell the *server* to send only a certain number of rows, rather than the server processing all these rows and the client just dropping them. Also, how is maxrows related to the fetch size of a ResultSet? As I understand it, the fetch size relates to the number of rows returned by the server to the client for each round trip to the database. So theoretically the two numbers are independent. There's no specified interaction except for the obvious one: requesting a fetch size exceeding the maxrows doesn't make sense since there will never be more than maxrows returned, and fetch size would effectively be ignored. Craig Thanks, David Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: question on Working with JavaDB Activities
Hi Joe, On May 3, 2007, at 3:52 AM, [EMAIL PROTECTED] wrote: I'm getting a command line error of 'javac' is not recognized as an internal or external command I presume there is a problem with my JAVA_HOME path, You probably should know that there is a difference between JAVA_HOME and PATH. PATH is where your operating system looks for the command, in this case javac. JAVA_HOME is where java (and javac and other executables) looks for other stuff once it starts executing. So your problem is not related to JAVA_HOME but to PATH. HTH, Craig Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: commit then read immediately
Hi, On Apr 18, 2007, at 3:05 AM, frederic barachant wrote: Hello. I have an application which initialises a database upon first start then immediately starts using it. Initialisation consists in writing objects through jpa. After commit is done, the program starts and reads back those data. Unfortunatly unless i set a slight sleep() after commit, data are not read back on first launch, so it seems that there is a delay between the moment when data is commited and the moment when it is accessible. This is of course not acceptable for my application as everything written must be immediately readable. Is my analysis correct? Immediately after a commit the data should be available to another Derby application (including other JPA implementations). But the behavior can be affected by caching done by the JPA layer. Are the reader and writer in different processes? Then caching is definitely on your list of to be investigated. If there's no caching, I can't think of anything that might cause this. Another possibility is that you are not managing relationships correctly (on both sides of the relationship). And the access pattern relies on navigating relationships instead of querying or finding instances by key. Is there a way to prevent this if it is a known behavior? It's unlikely that this is a Derby issue. Have you tried multiple JPA implementations? Have you asked this same question on your JPA implementation's forum? Good luck, Craig I am using derby 10.2.2 in jdk6u1 on XP. Thank you. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Regarding JPO -Enhancer
Hi Rohini, If you are using the example from the paper: C:\JPOX_Derbyjava -Dlog4j.configuration=file:src\log4j.properties -cp lib\bcel-5.1.jar;lib\jpox-enhancer-1.1.0-rc-1.jar;lib\jpox-1.1.0- rc-1.jar; lib\jdo2-api-2.0-rc1.jar;lib\log4j-1.2.12.jar;bin org.jpox.enhancer.JPOXEnhancer src\package.jdo The last line is the Meta-Data file that is referred to in the message. Did you use this command exactly (all on one line)? Regards, Craig On Apr 2, 2007, at 10:51 PM, rohini murlikumar wrote: Hi , When I am trying to run the enhancement-tool I get this message “ JPOX Enhancer (version 1.1.0-rc-1) : Enhancement of classes No JDO Meta-Data files specified!”.I have followed the same example as given in your paper in the below url. http://db.apache.org/derby/integrate/JPOX_Derby.html. Kindly let me know what is the solution? Regards, Rohini. Don't get soaked. Take a quick peek at the forecast with theYahoo! Search weather shortcut. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Using ij to connect to a Derby database
Hi Laura, On Mar 26, 2007, at 3:22 PM, Laura Stewart wrote: The text in the Getting Started Guide says: You can use the ij tool to connect to a Derby database. The word can implies that there is another way to connect to a Derby database. Is there? Any program can connect to a Derby database via the Derby driver(s). There is a finite but very large set of such programs. If not, we need to remove the word can from this sentence. I think the sentence is fine the way it is written. Craig -- Laura Stewart Craig Russell DB PMC, OpenJPA PPMC [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
Re: Naming the next Derby feature release
Speaking as a user of Derby, On Mar 1, 2007, at 12:04 PM, Rick Hillegas wrote: We wonder what the user community thinks. In particular: A) Would calling this release 11.0 make it less likely that you would be blindsided by these incompatibilities? Yes. A new major release number is a yellow flag that incompatibilities are likely and reading the release notes is mandatory. B) Would calling this release 11.0 make it less likely that you would install this release? No. The Derby community has a good reputation for quality and having a new release number makes it sound like lots of new features. Craig Craig Russell DB PMC [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
Re: Single Transaction Using Multiple Method Calls That Open New Database Connections
Hi Sisilla, You might look at using a java.lang.ThreadLocal to store the Connection or some object that stores more state including the Connection. Since you don't have to pass the Connection through multiple layers, it can make your code simpler and less messy. Craig On Feb 15, 2007, at 9:24 AM, Sisilla wrote: Thank you very much, David. I appreciate your time and consideration. I chose to use one Connection Object and pass it to all my methods so no new connections were opened. It makes my code messier, but I don't know anything about JTA. Again, thanks for the suggestion. ~Sisilla David Van Couvering-2 wrote: If you're using multiple connections, then you need to use JTA to have it work in a single transaction, and your database driver needs to support XA. If you're running in a J2EE environment with declarative transaction management enabled, you're good to go. If you're running in a web container, you may be able to get a reference to a UserTransaction object through JNDI (look up UserTransaction in Google). Some web containers provide JTA support, others don't and you'll need to get it from a third party. Others may provide details and/or corrections to what I say here, but that's the general idea. David Sisilla wrote: Hello All, I would like to update several tables in one transaction. The updates happen via several method calls, and each of these methods open new database connections. The methods also contain calls to other methods that open new database connections. Is it at all possible that these updates could be handled as a single transaction without eliminating these method calls? I am using conn.setAutoCommit(false); before the updates and conn.commit(); after the updates, but it isn't working as is. I am using Derby 10.2.1.6 and JDK 1.6.0 on Windows XP Professional. I appreciate any help. Thanks, Sisilla -- View this message in context: http://www.nabble.com/Single- Transaction-Using-Multiple-Method-Calls-That-Open-New-Database- Connections-tf3228984.html#a8989769 Sent from the Apache Derby Users mailing list archive at Nabble.com. Craig Russell DB PMC [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
Re: keeping the table ordered
It sounds like the issue is the structure of the rows on the data pages. IIUC, once a row is stored on a data page, it's going to be there for a long long time. So as you add new rows, they are added to data pages where there is free space. The only way to move a row is to delete it and insert it so it ends up in another place. It might be that for this purpose, you might have to restructure the database so that it is organized the way you want it. For example, perform an index scan based on the desired order and insert rows into a new table, which will have the effect of ordering the rows on data pages according to the insert order. If availability is an issue, you might have to partition the data so that while the old table is being reorganized into the new table, you keep track of insert and delete activity so you can apply the changes to the new table before putting the new table into service. Craig On Feb 6, 2007, at 10:08 AM, Mamta Satoor wrote: To answer your question on compound index. It just means to define an index which includes more than one column. eg CREATE TABLE t1(c1 INT, c2 INT, c3 INT, c4 INT) CREATE INDEX i1_2_4 ON t1(c1, c4, c2) HTH, Mamta On 2/6/07, Nurullah Akkaya [EMAIL PROTECTED] wrote: On Feb 6, 2007, at 11:25 AM, Michael Segel wrote: Sorry to top post, on my crackberry... I think you missed my point. Select the count of your documents that use the word 'the'. Ok so let's say that you want to search for all of the documents that use the word 'the'. You first lookup the integer representation of the word. Let's say that its = 100. How many times is the value 100 going to be in your index? that varies with the document set with 2 million documents i have around 2.5 million 'the' entries. Ok? But to your other point... You see that your data is not contiguous. Hmmm ok,so assuming that your primary index is wordID, how do you handle documents that have multiple words? So if you search on 'the' you'll get one set of data and if you then search on the wordID for 'is', you'll have data that isn't in sort order on the disk. assume the following ids. the - 100 is - 150 101 - linux i want my tables to be sorted like the following. not just the word the but all id's are sorted 100 100 100 100 100 100 101 101 101 101 150 150 150 from my knowledge of databases they sorted in random order thus we have indexes pointing where the data is. from the upper example i am going to read one big chunk of data from the disk but in the bottom example i will read 100 then jump a buch of records and read next. 100 101 150 101 101 100 150 where can i learn more about the compound index. create index statement in ref manual doesn't mention it? Now here's something that may help, Drop all of your indexes and create a single compound index where the first field is wordID. That may help you out... Sent via BlackBerry. -Mike Segel Principal MSCC 312 952 8175 -Original Message- From: Nurullah Akkaya [EMAIL PROTECTED] Date: Tue, 6 Feb 2007 11:14:02 To:Derby Discussion derby-user@db.apache.org Subject: Re: keeping the table ordered It is not quite clear to me what you are trying to achieve. Why do you want a sequential read? Scanning the entire table of 100 million records should take longer time than looking up a record using a index on wordid. Have you retrieved the query plan and made sure the index on wordid is used? Or are you talking about doing a lookup of many different wordids in sorted order? i did not meant sequential scanning of the whole table i meant disk i/o( bottom paragraph explains it ) yes i checked the query plan and derby uses index to lookup records and index look up checks only two index pages. so i came to the conclusion that most of the time is lost making random i/o request for the data thats why i am trying to keep the table sorted. since sequential hard disk access is much faster than random i/o . On Feb 6, 2007, at 8:09 AM, Michael Segel wrote: What exactly are you trying to do? Based on the little snippet, it looks like this is an exercise to create a google like search on a series of documents. The problem is that your wordID, while an integer, is not going to be unique enough. wordId isn't unique at all each word in a document gets a corresponding posting entry i look up wordId for the word the then select all docId's containg the wordId. that posting list is basicly a big inverted list. what i am trying to do is keep the table sorted by wordId so insted of keeping values randomly on disk they are being written sequentialy to the file so that instead of doing random i/o i just do a sequential read from the hard drive. i don't want sequential scanning of the whole table. For example, search your documents where the wordID is the integer look up for the word the. Do you see the problem? -- -- Michael Segel Principal
Re: Group By - problems
Hi Diego, The message is correct and Derby is behaving as it should. If you are using GROUP BY, you are aggregating a number of rows into a smaller number of rows, so instead of e.g. 100 rows all of which contain the same clienti.provincia, you aggregate all 100 rows into a single row. In order to do this, you need to either propagate the information you want (the GROUP BY items) or aggregate them using one of the aggregate functions MIN, MAX, AVG, SUM, etc. So you could e.g. aggregate clienti.birthday to find the youngest and oldest clienti in each provincia using SELECT provincia, MIN (clienti.birthday), MAX(clienti.birthday) FROM clienti GROUP BY clienti.provincia but this doesn't sound like what you are trying to do. From the looks of the query, you don't want the GROUP BY clause at all... Craig On Feb 5, 2007, at 1:31 PM, Diego Zanga wrote: lo, I'm using a query developed for mysql. actually it works with derby only IF there is NO group by clienti.id -- select clienti.id , clienti.cognome , clienti.nome , clienti.display , clienti.idtitolo, wk7.descrizione , clienti.indirizzo , clienti.citta , clienti.provincia , clienti.cap , clienti.idnazione, wk13.description , clienti.pi , clienti.codfis , clienti.idlegalerappresentante, wk17.display , clienti.birthday , clienti.born_prov , clienti.born_city, wk21.codicearchivio , clienti.note , clienti.phone1 , clienti.phone2 , clienti.phone3 , clienti.home_phone , clienti.fax , clienti.mobile1 , clienti.mobile2 , clienti.email1 , clienti.email2 , clienti.email_pec , clienti.fido , clienti.esposizione , clienti.tariffa_oraria from clienti left outer join subcliente on clienti.id = subcliente.idcliente left outer join pratiche as wk21 on wk21.id = subcliente.idpratica left join legale_rappresentante_cliente as wk17 on wk17.id = clienti.idlegalerappresentante left join nazione as wk13 on wk13.id = clienti.idnazione , titoli as wk7 group by clienti.id order by cognome,nome the query is developed by an engine, and is one of the smallest :OP the error is: java.sql.SQLException: The SELECT list of a grouped query contains at least one invalid expression. If a SELECT list has a GROUP BY, the list may only contain valid grouping expressions and valid aggregate expressions. I dont understand how the select could hold one invalid expression if without the group by it works: there's even no aggregate expression, so no invalid ones any idea? cya, thx -- Diego Zanga -- http://www.eLawOffice.it http://www.blogstudiolegale.eu http://www.javablog.eu Skype NAARANI Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: ERROR 08001:No suitable driver
Hi Mike, I've made that same mistake too many times to count. It sure would be a nice feature in ij for it to wait for the semicolon for a decent interval (1 minute?) and then ask the user if they are done typing yet ;-) Craig On Jan 18, 2007, at 8:22 AM, Dunk, Michael (Mike) wrote: Got a connection now. A missing quote and semi colon at the end caused it to hang. IJ seems like it should validate for simple mistakes like this. -Original Message- From: Dunk, Michael (Mike) Sent: 18 January 2007 16:09 To: Derby Discussion Subject: RE: ERROR 08001:No suitable driver After 40 minutes the command is still running, I assume that 40 minutes is too long just to create a test database. Should there be a timeout message? Could the database be locked? If so should a message be issued? Any ideas about how to trouble shoot this would be appreciated. Best regards, Mike -Original Message- From: Dunk, Michael (Mike) Sent: 18 January 2007 15:25 To: Derby Discussion Subject: RE: ERROR 08001:No suitable driver Thanks for the quick responses Kristian and Brian, I have entered connect 'jdbc:derby:mydb;create=true'; and will report back later with the results I will let this command run for a decent length of time, just to be sure that it has hung. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Columns of type 'REAL' cannot hold values of type 'CHAR'
Hi,
I'd like to suggest that you avoid the pattern of dynamic
construction of SQL, as in:
insertQuery = INSERT INTO basePlusCommissionWorkers +
VALUES ( ' + socialSecurityNumber + ', ' +
grossSales +
', ' + commissionRate + ', ' + baseSalary + ',
'0' );
Instead, use prepared statements and bind values from your GUI into
the statements. For example,
insertQuery = INSERT INTO basePlusCommissionWorkers +
VALUES ( ?, ?, ?, ?, '0');
The application will run much faster (and you will avoid the kinds of
issues you are having here).
Craig
On Dec 13, 2006, at 1:59 PM, William B. wrote:
I keep receiving the error message above when I try to add a
salary. Please help
import java.sql.*;
import java.awt.*;
import java.awt.event.*;
import java.util.*;
import javax.swing.*;
public class Workers extends JFrame {
private Connection connection;
private Statement statement;
private ResultSet resultSet;
private ResultSetMetaData rsMetaData;
private Container container;
private JTable table;
private JTextField input;
private JButton addSalariedWorker, addCommissionWorker,
addBasePlusCommissionWorker, addHourlyWorker;
// constructor Workers
public Workers()
{
super( Add Staff Members );
// The URL specifying the workers database to which this program
// connects to using JDBC
String url = jdbc:derby:workers;
// Load the driver to allow connection to the database
try {
Class.forName( org.apache.derby.jdbc.EmbeddedDriver );
connection = DriverManager.getConnection( url );
}
catch ( ClassNotFoundException cnfex ) {
System.err.println( Failed to load JDBC driver. );
cnfex.printStackTrace();
System.exit( 1 ); // terminate program
}
catch ( SQLException sqlex ) {
System.err.println( Unable to connect );
sqlex.printStackTrace();
System.exit( 1 ); // terminate program
}
// if connected to database, set up GUI
JPanel topPanel = new JPanel();
topPanel.setLayout( new FlowLayout() );
topPanel.add( new JLabel( Enter query to insert workers: ) );
input = new JTextField( 50 );
topPanel.add( input );
input.addActionListener(
new ActionListener() {
public void actionPerformed( ActionEvent e )
{
addWorker( input.getText() );
}
}
);
// create four buttons that allow user to add specific employee
JPanel centerPanel = new JPanel();
centerPanel.setLayout( new FlowLayout() );
addSalariedWorker = new JButton( Add Salaried Worker );
addSalariedWorker.addActionListener( new ButtonHandler() );
addCommissionWorker = new JButton( Add Commission Worker );
addCommissionWorker.addActionListener( new ButtonHandler() );
addBasePlusCommissionWorker =
new JButton( Add Base Plus Commission Worker );
addBasePlusCommissionWorker.addActionListener(
new ButtonHandler() );
addHourlyWorker = new JButton( Add Hourly Worker );
addHourlyWorker.addActionListener( new ButtonHandler() );
// add four buttons to centerPanel
centerPanel.add( addSalariedWorker );
centerPanel.add( addCommissionWorker );
centerPanel.add( addBasePlusCommissionWorker );
centerPanel.add( addHourlyWorker );
JPanel inputPanel = new JPanel();
inputPanel.setLayout( new BorderLayout() );
inputPanel.add( topPanel, BorderLayout.NORTH );
inputPanel.add( centerPanel, BorderLayout.CENTER );
table = new JTable( 4, 4 );
container = getContentPane();
container.setLayout( new BorderLayout() );
container.add( inputPanel, BorderLayout.NORTH );
container.add( table, BorderLayout.CENTER );
getTable();
setSize( 800, 300 );
setVisible( true );
} // end constructor Workers
private void getTable()
{
try {
statement = connection.createStatement();
resultSet = statement.executeQuery( SELECT * FROM
workers );
displayResultSet( resultSet );
}
catch ( SQLException sqlex ) {
sqlex.printStackTrace();
}
}
private void addWorker( String query )
{
try {
statement = connection.createStatement();
statement.executeUpdate( query );
getTable();
}
catch ( SQLException sqlex ) {
sqlex.printStackTrace();
}
}
private void displayResultSet( ResultSet rs ) throws SQLException
{
// position to first record
boolean moreRecords = rs.next();
// if there are no records, display a message
if ( !moreRecords ) {
JOptionPane.showMessageDialog( this,
ResultSet contained no records );
return;
}
VectorObject columnHeads = new VectorObject();
VectorObject rows =
Re: unique columns must be nullable ?
On Dec 12, 2006, at 4:28 PM, Mike Matrigali wrote: Craig L Russell wrote: On Dec 12, 2006, at 2:12 PM, Daniel Noll wrote: Mike Matrigali wrote: Out of curiousity what behavior does Hibernate expect when 2 nulls are inserted into a unique nullable column? That's my issue with unique nullable columns too. If it were to be truly unique you could only ever have one null in that column for the entire table, which would all but make it pointless to set it to null. I was not making a value judgement, just interested in what hibernate expected. I've heard arguments for both sides. As discussed in the referenced threads the reality is that the current underlying mechanism for implementing unique constraints are the underlying btree store indexes which unlike SQL compare NULL's as equal - What would break if we simply change this such that NULL always compares not equal with all other values including NULL? Aside from a number of test cases for this particular case... Craig which is why derby does not currently implement the optional SQL constraint on nullable columns. The other parts of SQL complient null handling happens outside of the storage system and complies with the described null comparison below. IIUC, a null value means that the value is unknown. So putting two nulls into the same column with a unique constraint makes sense to me. SQL is not Java, and NULL is not something that you can compare in SQL like you can in Java... And in the case of mapping to an optional 1-1 relationship, any number of rows can be associated with none of the above without any problems. Consider your DomesticPartner relationship. You are not required to have one, but if you do, you can have only exactly one. And if you have one, no one else can share it (legally). In any case I usually use a join table for optional 1-to-1 relationships anyway. It provides better forwards compatibility. For instance, if you ever have to upgrade that relationship to 1-to- many, you won't need to migrate anything. I agree with you that a join table for optional 1-1 relationships is the better choice. Then the join table columns can be defined as unique and you simply omit the values that otherwise would have to be null. Craig Daniel -- Daniel Noll Nuix Pty Ltd Suite 79, 89 Jones St, Ultimo NSW 2007, AustraliaPh: +61 2 9280 0699 Web: http://nuix.com/ Fax: +61 2 9212 6902 This message is intended only for the named recipient. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this message or attachment is strictly prohibited. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: unique columns must be nullable ?
On Dec 12, 2006, at 6:42 PM, Randy Letness wrote: Mike Matrigali wrote: Out of curiousity what behavior does Hibernate expect when 2 nulls are inserted into a unique nullable column? When you specify a unique constraint in hibernate, I'm pretty sure its only used by the schema export tools to generate a unique constraint when generating the DDL statements. That is, it doesn't care if you insert 2 nulls, it relies on the database to throw an exception. That's my understanding as well. If it's mapped to a toOne relationship, Hibernate expects that the database will not offer two rows to populate one relationship, but aside from that, it won't much care. On the outbound side, Hibernate might try to insert the second row with the same value if that's what the object model calls for, and expect the database to throw an exception. Things break when hibernate tries to generate a unique constraint on nullable columns in Derby. I guess its not smart enough to realize Derby (or any other db) doesn't support this. Hibernate does have database personality modules to reflect this kind of stuff. There might be a bug. It's probably worthwhile to make sure you have the latest code and if it still fails, a Hibernate forum question would probably result in at least a semi-official response. Hibernate is open source, and would probably be open to a patch if there is an issue. Craig I have run into the same problem as I am working on a project that supports both MySQL and Derby and MySQL supports constraints on nullable columns, while Derby doesn't. -Randy Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: 10.2 licensing issue...
Hi Geir, On Sep 12, 2006, at 9:17 AM, Geir Magnusson Jr wrote: A) I couldn't figure out how to build the dummy jars without cribbing templates from either the beta code or beta javadoc. To me this cribbing seemed like a forbidden, productive use of the beta-licensed distribution. What's the license on the spec? The spec license has the same restriction on implementations of JSR 220. If Derby were to build our own dummy jars then we would be an implementation of 220 not just a user of the classes defined in the spec. B) It seemed, frankly, a little sneaky and a violation of the spirit of the license. As I grok it, the spirit of the license is all about ensuring compatibility. Is there anything that you feel about what we're proposing in any way violates compatibility or puts it at risk for users? This is precisely the issue. A user of Derby 10.2 compiled with pre- release JDBC4 jars might get unexpected results if the final release jars differ from the pre-release jars. For example, constants from the compile jars get incorporated into the binaries and this conflict won't be detected via the normal compatibility checks. Craig geir Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: 10.2 licensing issue...
Hi Geir, On Sep 12, 2006, at 3:37 AM, Geir Magnusson Jr wrote: I read Rick's note on the 10.2 licensing issue in an archive because of strange move to the user list, so sorry for the weird quoting : This issue affects users of Derby just as much as developers. Users counting on a production release of Derby to be used with a production version of JDK6 with JDBC4 are directly affected by this change. Craig Craig Russell [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
Re: 10.2 licensing issue...
Hi Geir, I hate to be the broken record, but there are real user compatibility issues in releasing a production version of software that depends on pre-release versions of software. Real users can get hurt. Craig On Sep 12, 2006, at 9:57 AM, Geir Magnusson Jr wrote: Excuse me - I looked at the 220 license as noted by Craig below, not the *221* license, which is the one that actually applies. It turns out there are *no rights* enumerated for users as far as I can tell in the spec license. So the solution to this really annoying, tiresome and really avoidable problem is either : 1) Sun to put a user-oriented spec license that lets us just create those API jars and let us _compile_. 2) Sun to put the API binary jars for JDBC4 under CDDL or even the BCL. geir Geir Magnusson Jr wrote: Craig L Russell wrote: Hi Geir, On Sep 12, 2006, at 9:17 AM, Geir Magnusson Jr wrote: A) I couldn't figure out how to build the dummy jars without cribbing templates from either the beta code or beta javadoc. To me this cribbing seemed like a forbidden, productive use of the beta-licensed distribution. What's the license on the spec? The spec license has the same restriction on implementations of JSR 220. If Derby were to build our own dummy jars then we would be an implementation of 220 not just a user of the classes defined in the spec. Nah. Under the license currently for users on the JSR-220, I as a user have the rights for developing applications intended to run on an implementation of the Specification, provided that such applications do not themselves implement any portion(s) of the Specification The spec license - thank goodness - has no limitations on how I may use the specification to achieve the goal of developing applications intended to run on an implementation of the Specification, provided that such applications do not themselves implement any portion(s) of the Specification Given that : 1) We have no choice 2) we aren't going to ship the spec jars needed to compile 3) we aren't going to include them in our application and such jars are needed to build and ship applications intended to run on an implementation of the Specification I think we should go forward. B) It seemed, frankly, a little sneaky and a violation of the spirit of the license. As I grok it, the spirit of the license is all about ensuring compatibility. Is there anything that you feel about what we're proposing in any way violates compatibility or puts it at risk for users? This is precisely the issue. A user of Derby 10.2 compiled with pre-release JDBC4 jars might get unexpected results if the final release jars differ from the pre-release jars. Sure. There's always a possibility, but I think extremely unlikely, as we can test the resulting binary on the Genuine(tm) JDK from Sun. For example, constants from the compile jars get incorporated into the binaries and this conflict won't be detected via the normal compatibility checks. This sure would be easier if those Genuine(tm) spec jars were available under a reasonable license ... So, assuming we do a good job, do you think there will be a problem? geir Craig geir Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/ products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: 10.2 licensing issue...
On Sep 12, 2006, at 9:49 AM, Geir Magnusson Jr wrote: Craig L Russell wrote: Hi Geir, On Sep 12, 2006, at 3:37 AM, Geir Magnusson Jr wrote: I read Rick's note on the 10.2 licensing issue in an archive because of strange move to the user list, so sorry for the weird quoting : This issue affects users of Derby just as much as developers. Users counting on a production release of Derby to be used with a production version of JDK6 with JDBC4 are directly affected by this change. Isn't that the case with every aspect of development? Nah. Users care about their bugs and the features that they use, and the schedule for the next production release. The topic of discussion is about the schedule for the next production release. It was a judgement call, and I think it was the right one. Should we have a vote? ;-) Craig geir Craig Craig Russell [EMAIL PROTECTED] http://db.apache.org/jdo Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: NullPointerException in Derby client
Hi Robert, Please file a bug report in the Derby JIRA. Include the stack trace along with an ij script that creates the tables and a simple jdbc program that issues the query that causes the NPE. Someone on the Derby dev team will follow up. Thanks, Craig On Aug 28, 2006, at 4:56 AM, Robert Enyedi wrote: Hi, I receive a NullPointerException in the Derby client when trying to execute a prepared statement from iBATIS. This is the stack trace: org.apache.derby.client.am.SqlException: The exception 'java.lang.NullPointerException' was thrown while evaluating an expression. SQLSTATE: XJ001: Java exception: ': java.lang.NullPointerException'. at org.apache.derby.client.am.Statement.completeSqlca (Statement.java:1371) at org.apache.derby.client.am.Statement.completeOpenQuery (Statement.java:1042) at org.apache.derby.client.net.NetStatementReply.parseOpenQueryFailure (NetStatementReply.java:503) at org.apache.derby.client.net.NetStatementReply.parseOPNQRYreply (NetStatementReply.java:226) at org.apache.derby.client.net.NetStatementReply.readOpenQuery (NetStatementReply.java:56) at org.apache.derby.client.net.StatementReply.readOpenQuery (StatementReply.java:49) at org.apache.derby.client.net.NetStatement.readOpenQuery_ (NetStatement.java:151) at org.apache.derby.client.am.Statement.readOpenQuery (Statement.java:1038) at org.apache.derby.client.am.PreparedStatement.flowExecute (PreparedStatement.java:1396) at org.apache.derby.client.am.PreparedStatement.executeX (PreparedStatement.java:893) at org.apache.derby.client.am.PreparedStatement.execute (PreparedStatement.java:884) at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.ibatis.common.jdbc.logging.PreparedStatementLogProxy.invoke (PreparedStatementLogProxy.java:62) at $Proxy1.execute(Unknown Source) at com.ibatis.sqlmap.engine.execution.SqlExecutor.executeQuery (SqlExecutor.java:180) at com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.sqlExecute Query(GeneralStatement.java:205) at com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQue ryWithCallback(GeneralStatement.java:173) at com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQue ryForObject(GeneralStatement.java:104) at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject (SqlMapExecutorDelegate.java:561) at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject (SqlMapExecutorDelegate.java:536) at com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryForObject (SqlMapSessionImpl.java:93) at com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.queryForObject (SqlMapClientImpl.java:70) The SQL I'm running contains two inner joins, a WHERE and ORDER BY clause and two parameters. Both the parameters are in the WHERE clause. I did a short test with the 10.2.1.1 beta release too, but the error is the same. Any ideas on how I should deal with this internal server error? Thanks, Robert Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: NullPointerException in Derby client
On Aug 28, 2006, at 7:17 AM, Daniel John Debrunner wrote: Craig L Russell wrote: Hi Robert, Please file a bug report in the Derby JIRA. Include the stack trace along with an ij script that creates the tables and a simple jdbc program that issues the query that causes the NPE. Someone on the Derby dev team will follow up. There is no Derby team, Derby is an open-source community where anyone can get involved and work on improving Derby in many ways including fixing bugs. Of course, Dan has it right. What I meant by Derby team is the community of Derby contributors and developers who work on Derby. And if someone looks into the NPE and contributes a patch, then a Derby committer will have to actually apply the patch... Craig People work on what interests them: fry their own fish or scratch their own itch. Entering a bug may catch the interest of someone already active in the community, but it may not, there is no will about it. One sure way to get a bug fixed is to work in the community on fixing it. Here's an explanation of how development at Apache works: http://db.apache.org/derby/derby_comm.html#Understand+How +Development+Works+at+Apache The community is always ready to welcome new people. http://wiki.apache.org/db-derby/DerbyDev Dan. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: No suitable driver for ij
Hi Jeremy, Often the no suitable driver found message is an incorrect url, assuming that your classpath is set up ok (which is usually the case if you can get to the ij program itself). So what's your url? Craig On Aug 13, 2006, at 6:20 PM, Jeremy Foot wrote: I have derby working fine and can access it through various tools using the JDBC driver. I am trying to use the bundled ij tool to import some data from a csv file. ij runs fine and has the appropriate classpath, as far as I can tell. Certainly it has a path to the JDBC jar library, including file name. When I try to connect to derby, it fails with No suitable driver found. If the CLASSPATH was wrong, I would expect a ClassNotFound exception and a stack trace or is ij catching this? I am running Derby is 10.1.1 on Windose XP Gratefull for pointers and stuff I've already picked up from the list. Jeremy ___ Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: case insensitive searches
On Aug 9, 2006, at 4:27 PM, Farukh S. Najmi wrote: Stephen Caine wrote: Terry, Is it possible to set Derby to do case-insensitive searches? The default seems to be case-sensitive. This would be fine as a global setting that never needs to change. Are you using 'starts with', 'contains' or 'equals'? These operators tend to be case sensitive. Can you use 'like'? This is case insensitive. Stephen Caine Soft Breeze Systems, LLC You can also use UPPER function in your query predicate as in: ... AND UPPER(name) = 'CAINE' You should be aware that using UPPER(column) or LOWER(column) disallows the use of any indexes, so this should be a secondary qualifier for a query, not a primary qualifier. That is, if you want to have a case-insensitive search for name, where that's the only search qualifier, you are going to have the performance of a table scan, whereas if you are looking for a customer id within some range (customer id is indexed) and secondarily a case-insensitive search for name, that is ok. If you want an efficient case-insensitive query, you should consider adding another column to the table that contains the UPPER or LOWER translation of a column. Or add a soundex [1] column for better searches. Craig [1] http://en.wikipedia.org/wiki/Soundex -- Regards, Farrukh Web: http://www.wellfleetsoftware.com Blog: http://farrukhnajmi.blogspot.com Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: setNull in select doesn't work
Hi Knut, On Jul 25, 2006, at 12:11 AM, Knut Anders Hatlen wrote: Craig L Russell [EMAIL PROTECTED] writes: Hi Marieke, You have hit one of the big usability issues with SQL. While many vendors have implemented WHERE value = ? such that it behaves exactly like WHERE value IS NULL in case the parameter passed is null, it isn't required by the governing standard, and is not therefore a bug in an implementation but a feature. To be portable, you need to have different SQL statements in the case where the parameter is null versus not null. And if you have n parameters, you might have to have 2 ^ n different SQL statements, depending on whether each of the parameters is null or not. Sadly, this is the state of the art in today's database world. Hi Craig, Let's not get too negative. I don't think you need more than one statement. This is the simplest one, but it requires two calls to setNull/setXXX per parameter: select * from mytable where value = ? or (? is null and value is null) Yes, very creative, but unfortunately, this solution doesn't work for all databases either. :-( IIRC, Sybase throws an exception parsing ? IS NULL. Alternatively, this query requires only one setNull/setXXX per parameter and handles null: select * from (values (cast (? as varchar(128 params(value), mytable where mytable.value = params.value or (params.value is null and mytable.value is null) Not exactly beautiful, but it works! :) I believe the thesis of my reply is You have hit one of the big usability issues with SQL. I rest my case. Craig -- Knut Anders Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: setNull in select doesn't work
Hi Marieke,You have hit one of the big usability issues with SQL. While many vendors have implemented "WHERE value = ?" such that it behaves exactly like "WHERE value IS NULL" in case the parameter passed is null, it isn't required by the governing standard, and is not therefore a bug in an implementation but a feature.To be portable, you need to have different SQL statements in the case where the parameter is null versus not null. And if you have "n" parameters, you might have to have "2 ^ n" different SQL statements, depending on whether each of the parameters is null or not.Sadly, this is the state of the art in today's database world. CraigOn Jul 24, 2006, at 1:27 AM, Marieke Vandamme wrote:Hello, We are trying to perform a select query to the Derby database with PreparedStatement PreparedStatement ps = c.prepareStatement("select * from table where value = ?"); //several methods performed on statement (separately ofcourse) 1. ps.setNull(1,Types.VARCHAR); 2. ps.setObject(1, null, Types.VARCHAR); 3. ps.setString(1, null) ; The table contains null values, but the resultset is empty for the 3 cases. When executing statement with query "select * from table where value is null", we get the wanted results, but we need to do it with setting parameters in preparedstatement. We are using db-derby-snapshot-10.2.0.4-423199. Is this a bug? Do we need to set any special parameters/settings? Thanks! DISCLAIMER http://www.tvh.be/newen/pages/emaildisclaimer.html "This message is delivered to all addressees subject to the conditions set forth in the attached disclaimer, which is an integral part of this message." Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
Logging
Hi,Is there a simple way to have Derby log stuff? I've scoured the doc and can't really find much. What I'm mostly looking for is execution of SQL statements, results coming back from the database, etc. I know, pretty general, but I can't find anything at all on how to configure the logging to get anything at all.Thanks,Craig Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: should Clob.getSubstring() allow length of 0?
Hi Lance, On Jul 17, 2006, at 8:55 AM, Lance J. Andersen wrote: The JDBC methods should, as much as the possibly can, be consistent with the behavior of methods in the JDK. I agree with your point here. I think all of us are saying that there is no inconsistency with zero length Strings in JDK. All of the methods we've looked at are consistent with allowing the APIs to handle zero length Strings as a simple boundary condition. The only thing that's a bit hard to grok is the fact that JDBC generally uses 1-origin indexing while JDK uses 0-origin. But everything in the API allows zero-length Strings. This specific issue could easily be argued either way and I see it from a different point of view I haven't seen anything in your examples (once corrected) that give you a different point of view. Can you please re-read the thread and tell us where there is a problem? Craig Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: should Clob.getSubstring() allow length of 0?
Hi Lance, Now that Kathey has kicked it back to you and me, how about updating the to-be-released JDBC 4 to point out that a length of zero for the getSubString is valid? String getSubString(long pos, int length) throws SQLException Retrieves a copy of the specified substring in the CLOB value designated by this Clob object. The substring begins at position pos and has up to length consecutive characters. Parameters: pos - the first character of the substring to be extracted. The first character is at position 1. length - the number of consecutive characters to be copied We might simply add to this description. length - the number of consecutive characters to be copied; 0 is a valid value We have a similar case with Blob byte[ ] getBytes(). Can you run this past the expert group for a quick consensus? Thanks, Craig On Jul 14, 2006, at 11:13 PM, Kathey Marsden wrote: Craig L Russell wrote: You can always work around odd code on the other side of an incompletely defined interface. But you probably have code on the Derby side that also checks for the clob.length() == 0 and take some extraordinary action. So much easier for neither side to check for zero length and let the natural boundary condition happen. I am happy that you agree that the original DDLUtils code was perfectly reasonable at not as Lance described it. I will exit this issue now and allow you, Lance, or someone else with interest determine the correct behavior, check it with Derby and file a Derby bug if needed. Kathey Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: BigDecimal incompatibility from 1.5 - 1.4
Hi Ray,This sounds like a bug in the compiler. Have you raised an issue with the JDK folks?CraigOn Jul 13, 2006, at 9:38 AM, Ray Kiddy wrote:I have been e-mailing with Andrew McIntyre about getting some things done in the build of Derby on Mac OS X.We (at Apple) are seeing something and I am wondering how you all have dealt with this issue. At one time, we thought we could use Java 1.5 and achieve backwards compatibility with 1.4. We have seen an issue with BigDecimal and I wonder if this has impacted you all, or how you have dealt with it.The problem is this. If one used a method in 1.4, java.math.BigDecimal(int), the javac compiler would map this for you, under the covers, to java.math.BigDecimal(double).If one builds in 1.5 with no options, one gets the new API included in 1.5. So, java.math.BigDecimal(int) works as is and there is no reason for javac to do any magic underneath the covers.But, if one builds "javac -source 1.4 -target 1.4", then one gets the classes in the right class file format for running in the 1.4 VM, but the javac compiler has not done the mapping. Result? A runtime exception. The 1.4 VM does not know the method java.math.BigDecimal(int).The code below demonstrates this concretely.Just curious how you all are dealing with this, or if you have had to.thanx - ray% % echo "public class foo { public static void main(String[] arg) { java.math.BigDecimal d = new java.math.BigDecimal(10); System.out.println(d); } }" foo.java%% java -versionjava version "1.5.0_06"Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112)Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing)%%% javac -classpath . foo.java% % javap -c -classpath . fooCompiled from "foo.java"public class foo extends java.lang.Object{public foo(); Code: 0: aload_0 1: invokespecial #1; //Method java/lang/Object."init":()V 4: returnpublic static void main(java.lang.String[]); Code: 0: new #2; //class java/math/BigDecimal 3: dup 4: bipush 10 6: invokespecial #3; //Method java/math/BigDecimal."init":(I)V 9: astore_1 10: getstatic #4; //Field java/lang/System.out:Ljava/io/PrintStream; 13: aload_1 14: invokevirtual #5; //Method java/io/PrintStream.println:(Ljava/lang/Object;)V 17: return}%% /System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/Commands/javac -bootclasspath /Users/ray/Library/Java:/Library/Java:/System/Library/Java:/Network/Library/Java:/System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/Classes/classes.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/Classes/ui.jar -extdirs /System/Library/Java/Extensions -classpath . foo.java%%% /System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/Commands/javap -bootclasspath /Users/ray/Library/Java:/Library/Java:/System/Library/Java:/Network/Library/Java:/System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/Classes/classes.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/Classes/ui.jar -extdirs /System/Library/Java/Extensions -classpath . -c fooCompiled from "foo.java"public class foo extends java.lang.Object{public foo(); Code: 0: aload_0 1: invokespecial #1; //Method java/lang/Object."init":()V 4: returnpublic static void main(java.lang.String[]); Code: 0: new #2; //class BigDecimal 3: dup 4: ldc2_w #3; //double 10.0d 7: invokespecial #5; //Method java/math/BigDecimal."init":(D)V 10: astore_1 11: getstatic #6; //Field java/lang/System.out:Ljava/io/PrintStream; 14: aload_1 15: invokevirtual #7; //Method java/io/PrintStream.println:(Ljava/lang/Object;)V 18: return}% % javac -source 1.4 -target 1.4 foo.java% % javap -c -classpath . fooCompiled from "foo.java"public class foo extends java.lang.Object{public foo(); Code: 0: aload_0 1: invokespecial #1; //Method java/lang/Object."init":()V 4: returnpublic static void main(java.lang.String[]); Code: 0: new #2; //class java/math/BigDecimal 3: dup 4: bipush 10 6: invokespecial #3; //Method java/math/BigDecimal."init":(I)V 9: astore_1 10: getstatic #4; //Field java/lang/System.out:Ljava/io/PrintStream; 13: aload_1 14: invokevirtual #5; //Method java/io/PrintStream.println:(Ljava/lang/Object;)V 17: return}%- ray Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
Re: Deadline: Monitoring and Management Requirements for Derby June 18
I have to agree that the focus of the project should be on the implementation of the MBeans for Derby. Lots of clients can access the properties exposed by the MBean. Craig On Jun 19, 2006, at 3:11 PM, David Van Couvering wrote: Sanket Sharma wrote: What ever feature I deliver, will be through a nice GUI console or a web interface. I would argue it's more important to get the basic MBeans written and the JMX infrastructure in place before implementing a GUI. As of JDK 1.5 the tools include jconsole - see http://java.sun.com/ developer/technicalArticles/J2SE/jconsole.html. Do we really need to spend a lot of time building a GUI? Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: generated by default question
+1 Craig On Jun 14, 2006, at 4:07 AM, Bernt M. Johnsen wrote: Let me clearify some items from the SQL 2003 standard related to the latest mails regarding this issue from Craig and Michael: 1) In the case of generated always, it should not be possible to insert explicit values in identity columns, nor to alter generated values. 2) Internal and external sequence generators are by default not cyclical (Ch 9.22), so an exception will occur when they are exhausted (Ch 9.21) 3) In the case of a rollback, the sequence generator does not skip values, altough it may appear so. The standard says that commits and rollbacks of SQL-transactions have no effect on the current base value of a sequence generator. (Ch 4.21.1) It is the *use* of the generated value that is rolled back. 4) A sequence generator which for some reason skips a value (which is allowed), will not issue that value in the current cycle, since the current base value will be set to the highest value (or lowest if the generator is descending) issued in that cycle (Ch 9.21, general rules, part 4) Then again: 5) The behaviour of sequence generators is described independently of the context they are used in (as Craig correctly points out but with other words). 6) I can find no relation, whatsoever, defined in the standard between the existing values in a column and how the internal sequence generator of an identity column behaves. And finally: 7) How other databases (or Derby for that matter) implement a feature is no proof of standards compliancy. -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: generated by default question
Hi Mikey, On Jun 12, 2006, at 10:05 PM, [EMAIL PROTECTED] wrote: [mjs] I believe the problem is in how you're interpreting clause 3): 3) If there exists a non-negative integer N such that SMIN = CBV + N * INC = SMAX and the value (CBV + N * INC) has not already been returned in the current cycle, then let V1 be (CBV + N * INC). Otherwise, ... -=- It doesn't say what N is. That is to say... Suppose you have a sequence 0,1,2,3,4 inserted so that the next number should be 5. Yet suppose someone inserts a row with 5. Thus when you try to use 5, you generate an error. In sub-section 3), N could =6 or any number 6 but less than the MAX value of an integer. It can be interpreted that the sequence should attempt to generate N such that it doesn't fail on the insert This is where the idea of selecting the MAX() value in the identity column and incrementing it by one for the failed insert. And that would be a compliant solution. As I read this part of the specification, it refers to the generation of the sequence number, and not to the usage. The trick phrase is the value (CBV + N * INC) has not already been returned in the current cycle. As I understand returned it means returned by the sequence generator, and nothing to do with the usage as a column value. In fact, you could argue that if the implementation skipped returning a sequence value just because that value had been inserted by the user into a column, it would be a bug. Regards, Craig Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: generated by default question
Hi Mikey,
On Jun 13, 2006, at 10:47 AM, [EMAIL PROTECTED] wrote:
by default question
Hi Mikey,
On Jun 12, 2006, at 10:05 PM, [EMAIL PROTECTED] wrote:
[mjs]
I believe the problem is in how you're interpreting clause 3):
3) If there exists a non-negative integer N such that SMIN =
CBV + N
* INC = SMAX and the value (CBV + N * INC) has not
already been
returned in the current cycle, then let V1 be (CBV + N *
INC). Otherwise, ...
-=-
It doesn't say what N is. That is to say...
Suppose you have a sequence 0,1,2,3,4 inserted so that the next
number
should be 5. Yet suppose someone inserts a row with 5. Thus when
you try to
use 5, you generate an error. In sub-section 3), N could =6 or any
number 6
but less than the MAX value of an integer.
It can be interpreted that the sequence should attempt to generate
N such
that it doesn't fail on the insert
This is where the idea of selecting the MAX() value in the identity
column
and incrementing it by one for the failed insert.
And that would be a compliant solution.
As I read this part of the specification, it refers to the generation
of the sequence number, and not to the usage. The trick phrase is
the value (CBV + N * INC) has not already been returned in the
current cycle. As I understand returned it means returned by the
sequence generator, and nothing to do with the usage as a column
value.
In fact, you could argue that if the implementation skipped returning
a sequence value just because that value had been inserted by the
user into a column, it would be a bug.
Regards,
Craig
[mjs] Hi Craig,
Errr. No.
In short, the sequence generation is outside of the transaction,
therefore
its possible to get a jump in the sequence number due to transactions
rolling back or individual inserts failing due to additional
constraints.
Not my point.
Please note that I'm assuming an incremental value of 1 to prove
the point.
If the sequence use a different value for its increment, then you
will have
to adjust the logic a bit.
Here's the section 4.21 language:
When a row R is presented for insertion into
BT, if R does not contain a column corresponding to IC, then
the value
V for IC in the row inserted into BT is obtained by applying the
General Rules of Subclause 9.21, Generation of the next value
of a
sequence generator, to SG.
All this defines is the default instead of always behavior.
Ok so you're looking at what they term is a general rule. (Not
going to
define what *that* means.
However looking at 9.21,
9.21 defines a mathematical statement. And the solution under 9.21
is really
a solution set. There a potential of (MAX - CBV)/INC elements (and
the empty
set) that could be applied where CBV MAX.
ok.
Your suggestion violates this because the number of possible values
for N
will be = 1 iff (MAX-CBV)/INC 1.
no. What I'm saying is that the sequence generator is defined to
return all values between the start and max value without skipping
any. And at the risk of repeating myself, this is behavior of the
sequence generator not the constraint on the column values.
IF you return a sequence value N that meets the criteria, then
you're not
violating 9.21.
Note again that this is a generalization and that implementations
of these
rules can vary.
The first piece of the fix would be to do the following logic:
If (row inserted contains a value R that corresponds to IC) {
After Insert:
If ( R CBV) Then CBV=R; // Or R+1;
} else {
CBV += INC; // INC = incremental value
}
Sorry for the bad pseudo code.
The idea is that you'll always be setting CBV to the max value when
someone
inserts a row with their own identity value that is greater than
the current
base value.
You still haven't responded to my main point:
As I read this part of the specification, it refers to the generation
of the sequence number, and not to the usage. The trick phrase is
the value (CBV + N * INC) has not already been returned in the
current cycle. As I understand returned it means returned by the
sequence generator, and nothing to do with the usage as a column value.
Simply put, the sequence generator must return all legal values of
SMIN return-value SMAX before reusing a return-value.
This is what Informix appears to be doing with their Serial value.
Of course when you cycle over, then you have to worry about the
issue what
happens if the row already has a value in it. And that's the next
issue.
Sorry, but this is still a bug. The current version of Derby does
violate
the specs as stated here.
Sorry, not convinced.
Craig
Look at it this way. As long as a value N exists between the bounds
of CBV
and MAX, you will always have a sequence number.
By following this logic, and going through a single cycle, you will
always
have either a value or an empty set when MAX - CBV INC.
-G
Re: generated by default question
Hi, On Jun 13, 2006, at 11:01 AM, Craig L Russell wrote: In fact, you could argue that if the implementation skipped returning a sequence value just because that value had been inserted by the user into a column, it would be a bug. I withdraw this argument after re-reading the words. It is legal to skip over some number of values as long as you remember which values were skipped over so that you don't cycle before returning all of them. Craig Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: generated by default question
Hi G, On Jun 13, 2006, at 12:07 PM, Michael Segel wrote: If there exists a value N such that you can return V1 that doesn't throw an exception due to the unique constraint on the identity column, then the sequence should return that number. Or rather Derby should trap for this and determine how to find a value N if it exists. If N does not exist, then you should indicate that the table is full. Cycling through my earlier comments now. The generator and the unique constraint checking are orthogonal concepts. Craig Failing to do so would mean that there is a design defect that needs to be corrected. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: JMX Extensions to Derby
On Jun 1, 2006, at 1:51 AM, Bernt M. Johnsen wrote: Øystein Grøvlen wrote (2006-06-01 09:24:18): Sanket Sharma wrote: I would also appreciate your suggestions on features the community would like to see being implemented as JMX extensions. On the top of my head: - Performancs statistics (e.g., transactions committed/aborted per second) - Change dynamic properties (e.g., derby.storage.pageSize) - Stop a network server (would require some kind of authorization) A question: How will JMX work in an embedded environment? Will it be possible to connect from another process? If yes, if yes that introduces security issues that one today does need to address for an embedded configuration. I suggest that the distributed services level should be optional. Only the agent level and the instrumentation level should be there by default. This will also comply with the current Derby architecture with embedded vs. the network server. Let me restate to make sure I understand what you're proposing (with a bit of embellishment of my own). The jmx services are not started automatically, and if the user only uses jdbc to access Derby, jmx will not be used. If the user invokes a method on a Derby-provided jmx bootstrap class (don't know the jmx terminology here -- please help) then the jmx infrastructure would be initialized and the jmx services would be available to the program. The jmx services might be used to start and stop databases, get statistics about whether a database was running, how much disk space was being used, make a backup, restore from a backup, etc. To get to the data inside the database, you would still connect to a Derby database via jdbc. Another level of service is to make the jmx services available outside the vm of the owning Derby database. This is similar to what we do now when we start the network server. There might be several ways to start the jmx services from the vm, including a - Dorg.apache.derby.StartJMX=true command line flag or via API. The API version would need permissions granted to the caller's jar file. Did I get it? Craig -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Dublin anyone?
I'm not a derby committer, but I do plan to attend ApacheCon in Dublin later this month. I've got a presentation on Friday.Craig Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: 10.2.0.1 snapshot posted
Hi Rick, One question: Why is the snapshot called 10.2.0.1 and not just 10.2? It sounds from the name like this is the first patch after the release of 10.2. I must be missing something. I was expecting the file to be called db-derby- snapshot-10.2-409481.zip not db-derby-snapshot-10.2.0.1-409481.zip. I also see on the snapshots page that: Latest Official Release 10.1.2.1 (Nov 18, 2005 / SVN 330608) but later on in the same page it appears that 10.1.2.2 and 10.1.2.3 were released already. Thanks, Craig On May 26, 2006, at 2:50 PM, Rick Hillegas wrote: Hello users and developers, We have posted a new snapshot of the mainline, which we expect will evolve into the 10.2 release this fall. You may find the snapshot at http://db.apache.org/derby/derby_downloads.html#Snapshot+Jars. We would be grateful if you would test-drive this snapshot and post your feedback to the community. Since the last snapshot (early March), a great deal of work has committed, including planned improvments to Scrollable Updatable ResultSets, JDBC4. and the internationalization of the network client. Many bug fixes have committed also. For more information on the snapshot's contents, please see http://wiki.apache.org/db-derby/ TenTwoSnapshot. We also want your feedback on work which appeared in the previous snapshot, including online backup, unary +/- on parameters, query timeout, more configurable identity columns, more builtin functions, and better network security. Thanks! -Rick Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: 10.2.0.1 snapshot posted
Hi Rick, In the JDO project, I define a dependency on Derby via maven pom: dependency groupIdorg.apache.derby/groupId artifactIdderby/artifactId version10.1.1.0/version /dependency dependency groupIdorg.apache.derby/groupId artifactIdderbytools/artifactId version10.1.1.0/version /dependency In order for me to test your snapshots, there's a lot of manual stuff to do, downloading the jar, unzipping into a directory, copying the jar files into my local maven repository; and then I get run my scripts to actually test the bits. Would it be possible for you to post the snapshot bits to a maven repo so I can just point maven at it and automatically get the latest snapshot for testing? We have done this for JDO jars and it works great. We put the JDO release artifacts into e.g. people.apache.org/ ~clr/dist/java-repository/org.apache.jdo/jars/jdo2-api-SNAPSHOT.jar and point maven.remote.repo at people.apache.org/~clr/dist/java- repository. With the Derby jar files posted in this way, we could contribute more easily to the testing effort. Thanks, Craig On May 26, 2006, at 2:50 PM, Rick Hillegas wrote: Hello users and developers, We have posted a new snapshot of the mainline, which we expect will evolve into the 10.2 release this fall. You may find the snapshot at http://db.apache.org/derby/derby_downloads.html#Snapshot+Jars. We would be grateful if you would test-drive this snapshot and post your feedback to the community. Since the last snapshot (early March), a great deal of work has committed, including planned improvments to Scrollable Updatable ResultSets, JDBC4. and the internationalization of the network client. Many bug fixes have committed also. For more information on the snapshot's contents, please see http://wiki.apache.org/db-derby/ TenTwoSnapshot. We also want your feedback on work which appeared in the previous snapshot, including online backup, unary +/- on parameters, query timeout, more configurable identity columns, more builtin functions, and better network security. Thanks! -Rick Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: 10.2.0.1 snapshot posted
Hi Dan, Thanks for confirming that 10.1.2.1 is the latest. Craig On May 26, 2006, at 4:01 PM, Daniel John Debrunner wrote: Craig L Russell wrote: I also see on the snapshots page that: Latest Official Release 10.1.2.1 (Nov 18, 2005 / SVN 330608) but later on in the same page it appears that 10.1.2.2 and 10.1.2.3 were released already. No, the latest official release is 10.1.2.1. The version number has been bumped on the 10.1 branch but there has not be any official release since 10.1.2.1, ie. one voted on by the community. I think the practice has been to bump the last digit when a snapshot is posted, remember a snapshot is just a snapshot of the current code line posted by a committer. The current policy is to bump the third digit for an official release from a branch, so the next official release for 10.1 will be 10.1.3.x. See http://wiki.apache.org/db-derby/TenOneThreeRelease Dan. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: 10.2.0.1 snapshot posted
Hi Rick, On May 26, 2006, at 4:40 PM, Rick Hillegas wrote: Hi Craig, My snapshot instructions directed me to bump the last digit of the release identifier to distinguish this increment from the previous snapshot. That earlier snapshot was called 10.2.0.0. The zip names were invented by the snapshot target of our release scripts and mimic the same conventions as the March snapshot. But the name of the distribution is db-derby- snapshot-10.2.0.1-409481.zip so you already have the disambiguating svn release number in the file name. My money is on a simpler name to avoid the kind of confusion I have with 10.2.0.1. Does this mean that the official release might actually be something like 10.2.0.8, considering the number of cycles that we might go through over the next several months? I'm sure I can get used to it, but first impression is that this is off... Craig I believe that 10.1.2.1 is the latest official release and the next official release will be 10.1.3.x. At least the date on 10.1.2.1 looks right to me: the community hasn't vetted a release since last fall. I too am puzzled by 10.1.2.2 and 10.1.2.3. Perhaps these are patch distributions, cut off the living, growing end of the 10.1 branch and given to targetted customers. Can anyone else shed light on this? Regards, -Rick Craig L Russell wrote: Hi Rick, One question: Why is the snapshot called 10.2.0.1 and not just 10.2? It sounds from the name like this is the first patch after the release of 10.2. I must be missing something. I was expecting the file to be called db-derby- snapshot-10.2-409481.zip not db-derby-snapshot-10.2.0.1-409481.zip. I also see on the snapshots page that: Latest Official Release 10.1.2.1 (Nov 18, 2005 / SVN 330608) but later on in the same page it appears that 10.1.2.2 and 10.1.2.3 were released already. Thanks, Craig On May 26, 2006, at 2:50 PM, Rick Hillegas wrote: Hello users and developers, We have posted a new snapshot of the mainline, which we expect will evolve into the 10.2 release this fall. You may find the snapshot at http://db.apache.org/derby/ derby_downloads.html#Snapshot+Jars. We would be grateful if you would test-drive this snapshot and post your feedback to the community. Since the last snapshot (early March), a great deal of work has committed, including planned improvments to Scrollable Updatable ResultSets, JDBC4. and the internationalization of the network client. Many bug fixes have committed also. For more information on the snapshot's contents, please see http://wiki.apache.org/db- derby/ TenTwoSnapshot. We also want your feedback on work which appeared in the previous snapshot, including online backup, unary +/- on parameters, query timeout, more configurable identity columns, more builtin functions, and better network security. Thanks! -Rick Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: 10.2.0.1 snapshot posted
Hi Andrew, I hadn't seen this jewel before. Thanks for letting me know that the release numbering scheme is well-established and consistent. Craig On May 26, 2006, at 8:38 PM, Andrew McIntyre wrote: On 5/26/06, Craig L Russell [EMAIL PROTECTED] wrote: Does this mean that the official release might actually be something like 10.2.0.8, considering the number of cycles that we might go through over the next several months? From http://db.apache.org/derby/papers/versionupgrade.html: Fixpack (f) of 0 (zero) is a special value that indicates alpha quality software and causes version string to be appended with the word 'alpha'. Additionally a boolean beta flag exists, which when true causes the version string to be appended with the word 'beta' to indicate beta quality software. So, the first real release candidate would have both the third digit bumped to 1, the fourth digit zeroed out, and the beta flag set to false. So the first release off of 10.2 will be (at least) 10.2.1.0. If there's a formal beta period and Rick decides to make the beta 10.2.1.0, then the first real release candidate might be 10.2.1.1. That's up to him. :-) andrew Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Out of Memory
Hi, Often, memory leaks are caused by not closing statements or result sets. If you post the program that leaks, we might be able to help you figure out if it's a problem in your application or a problem in Derby. Regards, Craig On May 15, 2006, at 5:02 AM, Michael Andreasen wrote: I am running derby in embedded mode using EmbeddedSimpleDataSource and I am running out of memory. If I start with an empty, newly created database, and try to do a loop that just keeps inserted records, I get an out of memory error after it has inserted about 12,000 rows. I am running a small application with the -Xmx8m set, when it begins inserting free memory is about 6m. As it runs this goes down and down until I get an OutOfMemory Exception. It is as if every insert is being cached? Any ideas? Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Javadoc lies
Hi Rick, On May 8, 2006, at 6:43 AM, Rick Hillegas wrote: Thanks to Andrew, Craig, and David for your responses. I agree with Andrew that writing custom doclets sounds like a lot of tricky work. I like Craig's suggestion that we ship two sets of public javadoc, a JDBC3 javadoc for users who run on jdk1.3-1.5 and a JDBC4 javadoc for users who run on jdk1.6. We could prune irrelevant classes from each set. Besides solving the immediate problem, this approach would be less confuing. Right now the composite javadoc, which contains both the JDBC3 and JDBC4 apis mixed together, is puzzling. Craig's solution would look like this: i) We would generate the JDBC3 api using the 1.4 javadoc tool. The missing subclass references shouldn't confuse customers because the subclasses wouldn't appear in the JDBC3 api. ii) We would generate the JDBC4 api using the 1.6 javadoc tool. This api would not contain the lying classes from the JDBC3 api. iii) We would bolt a webpage on top of the top apis, explaining which api to consult, based on the client VM. Does this sound acceptable? It sounds good to me. While it is a bit inconvenient having to specify at the bolted web page which API you're interested in, I think it's better than finding out the hard way that the javadoc info is incorrect. Craig Thanks, -Rick Craig L Russell wrote: Hi Rick, I'm intentionally cross-posting to derby-user just because lies in javadoc are supposed to affect users, not only developers. How about: 3. Build two sets of javadoc, one using jdk 1.4 and another using 1.6. Distribute both sets of javadoc. Require the user to choose which javadoc to use based on which jvm she chooses to run. Tell no lies. I'm sure I'm missing something; hopefully it's not obvious. :-) Craig Thanks to everyone who responded to this thread. It doesn't seem that anyone has a solution to this problem. Does anyone have a preference for which lie we tell: (1b) or (2d)? Barring a preference here, the default would be (1b), our current behavior. Thanks, -Rick Rick Hillegas wrote: Right now the javadoc generated for jdk1.6 is telling a shocking lie. I can fix this but only by inducing javadoc to tell a different lie. I would like advice on how to get javadoc to tell the truth, the whole truth, and nothing but the truth. If that's not possible, I'd like to know which lie the community prefers. 1) How it is today. Right now, if you point your ant.properties at a 1.6 installation, we build javadoc with the 1.6 javadoc tool. The tool assumes that you built your whole classtree against 1.6 and that the compiler therefore caught certain kinds of errors. In particular, if a class successfully compiles under jdk1.4 against the jdk1.4 version of an interface, then the 1.6 javadoc tool assumes that the class implements additional methods added to that interface in jdk1.6. Here's an example of the problems this causes: a) EmbeddedDataSource, compiled under jdk1.4, implements the 1.4 version of javax.sql.DataSource b) The 1.6 javadoc falsely says that EmbeddedDataSource implements the Wrapper methods added to javax.sql.DataSource by jdk1.6 2) A possible fix and its countervailing lie It would be possible to use the 1.4 javadoc tool to build javadoc for all the classes compiled under 1.4. Then we could use the 1.6 compiler to build the whole classtree again. With a little jiggery-pokery, we might be able to copy the additional javadoc html into the 1.4 javadoc tree and use the 1.6 index.html to zipper the two trees together. Mind you, I haven't built this yet, I'm just waving my hands. For the example case above, we would end up with something like the following: c) EmbeddedDataSource would NOT assert that it implements the jdk1.6 Wrapper methods d) However, now EmbeddedDataSource would fail to say that it has an important subclass, EmbeddedDataSource40 3) Other solutions? Does anyone have a better solution? Better means easier and/or more truthful. 4) Lies and the lying liars who like them If not, which lie do you prefer: (1b) or (2d). Thanks, -Rick Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: [WWD] Review of Final Chapters (5 and 6)
Hi Stan, When you get around to discussing architecture issues, you might make sure you get feedback from the derby experts. My understanding is that you can use the embedded Derby with both same-vm clients and outside-vm clients by starting the network server when you start the embedded database. Craig On May 3, 2006, at 2:21 PM, Stanley Bradbury wrote: John Embretsen wrote: === SNIP === quote 1 from Activity notes, p.6 (8) A client program is often created to allow database access and updates from multiple computers on the network. /quote I don't think this statement is correct. It is not the client program that allows access from multiple computers, it is the server framework that does this. Would you like to rephrase? quote 2 from Activity notes, p.6 (8) Derby's two architectures have caused confusion for some new Derby users. They mistakenly think that embedded is a single user configuration. Not true. The embedded driver supports multiple simultaneous connections, performs locking and provides performance, integrity and recoverability. /quote I think this is still confusing. I think you should add a comment saying that the embedded driver must *not* be used to access the same database from more than one JVM simultaneously. The multi- user capabilities you are describing are (as far as I know) only valid if all users use the same JVM/Derby system (i.e. the same instance of the embedded driver), or if no users using different JVMs/Derby systems access the same database at the same time. Hi John - Thanks again for your attention and feedback. Both suggestions are well taken. The sentence about the reason to create a client program is not well constructed and is inaccurate. I also see that it does not carry the message I intended and I will rephrase it. The other note is what I think of as an 'endorsement of the embedded architecture'. I included it to get people thinking / questioning along the lines you are, I have been successful in that regard. I think it an important endorsement to make because I have seen many people new to Derby avoid embedded without really thinking it through. It is my sense that the copious warnings about 'double booting' scares them away from embedded. After working with Derby for awhile these people see that the embedded driver fully supports their need and is a cleaner and faster implementation. I wanted to plant that seed of an idea. It is arguable that the topic does not belong in an introductory document at all because it deals with system architecture as well as the specific meaning of terms like 'single-user', 'client- server', 'networking' and 'interprocess communication'. Clearing up the confusion is out of the scope of this document. Your suggestion, however, has me thinking I should draft a short paper on the topic that can be referred to when questions like yours are raised and will begin working on this. Do you think this will help with the issue you raise? I hesitate to include the standard caution about access from multiple-JVMs as I perceive this as contributing to the mind-set that using the embedded driver is limiting. I would really like to hear your thoughts on this and maybe begin a new thread on the topic of when to use Network Server and when the embedded driver is sufficient. It seems there is enough in this topic for a lively discussion. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: SecurityException on mail.jar and activation.jar
Hi Hans, Have you double checked your path to make sure the jar you verified is the jar that's being used? Craig On May 1, 2006, at 11:56 PM, Hans Cappelle wrote: I really think this is a Derby issue. Had some conversation with a developer of sun who told me they indeed can only sign jars for 1 year, so every year they have to release the same software. He told me to use the latest release. Which I did. I used JavaMail: 1.3.3 and even 1.4 EA. 1.4 was released december 2005 so this should still be valid. Also these jars verify successfully with the jarsigner provided by Java: jarsigner -verify jar-file No one else having these kind of problems? 2006/4/26, Stanley Bradbury [EMAIL PROTECTED]: Hans Cappelle wrote: We got this exception on mail.jar and activation.jar stored in our derby database. Both latest releases and other versions of Derby (like latest nightly build) did not help. Setting system clock before 26 01:59:59 or replacing jars with unsigned jars is only solution we could find. 2006-04-26 10:43:19 ... org.apache.derby.client.am.SqlException: The exception 'java.lang.ExceptionInInitializerError' was thrown while evaluating an expression. SQLSTATE: XJ001: Java exception: ': java.lang.ExceptionInInitializerError'. SQLSTATE: XJ001: Java exception: 'Security exception thrown accessing class javax.mail.MessagingException in jar TEST.MAIL : NotAfter: Wed Apr 26 01:59:59 CEST 2006: java.lang.SecurityException'. Thanks for any help. Hi - This is a JavaMail issue. The certificate associated with the signed jars has expired. You need to update the certificate or obtain a version of the files with an updated certificate. -- Hans Cappelle Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Query and uppercases
If you are concerned about performance, please note that there is a huge difference between these two statements: 1. SELECT * FROM CITY_INFO WHERE UPPER(?) = CITY_NAME and 2. SELECT * FROM CITY_INFO WHERE ? = UPPER(CITY_NAME) Query 1 will work if your data is already upper case. You can do an index scan of the table very quickly. If your data is stored in mixed case, you need query 2, and this will need to do a table scan because there is no index on the UPPER (CITY_NAME) values. [AFAIK there is no way to implement such an index on the column. So the index needs to be created with the upper case names. If you need mixed case in the database, you might need another column just for the upper case index. Craig On Apr 26, 2006, at 8:52 AM, Bryan Pendleton wrote: Is there a way to bypass this, so when querying the database it does not look at uppercases or lowercases. è Detroit = detroit = dEtRoIt = … Try using the UPPER function: select * from city_info where UPPER(city_name) = 'DETROIT'; thanks, bryan smime.p7s Description: S/MIME cryptographic signature
Re: How to find master record primary key to use it in inserting details records
Hi Legolas, If you're using JDBC, you can use the Statement.getGeneratedKeys() method. You define the master table with the primary key column being IDENTITY. You insert a row using Statement.execute(), call getGeneratedKeys, and the ResultSet returned from the method contains the value of the IDENTITY primary key you just inserted. Craig On Apr 12, 2006, at 12:39 AM, Legolas Woodland wrote: Hi Thank you for reading my post I have two tables which are related to eachother using a column (master details) my problem is that master table primary key is auto increment so when i insert a recoed to it i can not determine the primary key value so i do not know the key , Now my problem is that how i can find the primary key of master record to use it when i inert details records ? I should say that it is a very high hit application , before i post this message i though that i can execute a query and select latest inserted record but latest inserted record could be from another user not the current user. Thanks Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: PreparedStatement Persistance
On Apr 5, 2006, at 10:31 AM, Daniel John Debrunner wrote: Daniel Morton wrote: Over the past few threads, someone mentioned that the PreparedStatements are cached on the database even when the connection that created the PreparedStatements are closd... I was discussing that very issue with an associate of mine a couple of weeks ago, and he assured me that the Oracle and DB2 people he knew told him that the PreparedStatements did not persist between connections. Is that incorrect, or does Derby just handle it differently? PreparedStatements are not cached in Derby, however the compiled plan of the statement is cached across connections, and can be shared across connections. It is this compiled plan that takes the significant amount of time to create. PreparedStatements are really a wrapper around the compiled plan that maintans state specific to that statement and connection. Most databases have this ability to cache the compiled plan, to avoid re-compilation across connections. I agree completely with what Dan says here (he is the expert). I would just like to add that this is an example of making sure to ask the right question. If you ask about the PreparedStatement instances being reused between Connections, then you may be concerned about memory, footprint, garbage collection, and other issues. If you ask about the performance of reusing query statements across Connections, that's a completely different issue, as Dan explains. There is yet another subtlety and that is that the cached compiled query plan is a back end concept, and doesn't necessarily translate to anything on the front end where jdbc lives. Craig Dan. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: unable to execute procedure
Hi Dan,
May I suggest that if you are writing samples for others to use
that you
demonstrate use of parameter markers in PreparedStatements. This will
perfom better on Derby and all other relational database engines.
I think this is a very important point, and if you look at the
procedure, you might think that there is no value in using prepared
statements, as the statement appears as if it is only going to be
executed once. But preparing the statement allows Derby to cache the
statement the first time, and to find an identical statement (with
parameter markers) in the cache on subsequent invocations, even if
you close the Connection. If you bind the values into the prepared
statement, there is little chance that Derby will find the statement
in the cache.
Craig
On Apr 4, 2006, at 9:48 AM, Daniel John Debrunner wrote:
Anil Samuel wrote:
public class LeaveHelper {
public static int TotalLeaveForType(String employee, int
leaveTypeId)
{
int total = 0;
try {
Connection con = DriverManager.getConnection(
jdbc:default:connection);
PreparedStatement ps = con.prepareStatement(select
TOTAL_TAKEN
from DTP.LEAVE_APPROV where EMPLOYEE_ID= + employee + and
LEAVE_TYPE_ID=
+ leaveTypeId);
ResultSet rs = ps.executeQuery();
ps.close();
con.close();
total = rs.getInt(1);
}
catch (SQLException e)
{
e.printStackTrace();
}
return total;
}
}
Couple of problems with the code:
- You close the PreparedStatement ps before using the ResultSet
rs. By
JDBC rules the close of ps will also close rs.
- You don't call rs.next() on the ResultSet, thus the rs.getInt
will fail.
May I suggest that if you are writing samples for others to use
that you
demonstrate use of parameter markers in PreparedStatements. This will
perfom better on Derby and all other relational database engines.
Here's a reworked version
public static int TotalLeaveForType(String employee, int
leaveTypeId) throws SQLException
{
int total = 0;
Connection con = DriverManager.getConnection(
jdbc:default:connection);
PreparedStatement ps = con.prepareStatement(select
TOTAL_TAKEN
from DTP.LEAVE_APPROV where EMPLOYEE_ID=? and LEAVE_TYPE_ID=?);
ps.setString(1, employee);
ps.setInt(2, leaveTypeId);
ResultSet rs = ps.executeQuery();
rs.next();
total = rs.getInt(1);
rs.close();
ps.close();
con.close();
return total;
}
}
Dan.
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
Re: [web] Derby site reorganization (resend)
Hi Jean, On Mar 27, 2006, at 5:04 PM, Jean T. Anderson wrote: I just hate it when you hit the wrong key and something gets sent before it's ready. Here's a resend. I reorganized the Derby web site and put a review copy here: http://people.apache.org/~jta/DerbyTest/ I never had an issue with the blue side bar. The background seems to be missing now. I kinda liked (+0) the old blue. The main modifications include: 1) Added a Quick Start tab with tips for getting started. This is nice. 2) Added a Download tab to make downloads easier to find. This is nice. 3) Renamed Manuals tab to Documentation. I also moved the links from the left-hand navigation to the body of the page, so they can be opened in a new browser window. This will make it easier to jump between manuals; you won't have to hit the back key repeatedly to get back to the main manuals page. 4) Renamed Integration tab to Resources Integration has always struck me as very specific and not everyone might understand what it means. Do you have any suggestions? Nothing specific. Good job. Craig I plan on committing these changes on Thursday and will incorporate any feedback I receive before then. regards, -jean Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: SQL Exception
Hi Michael,
Nice to see you're back.
On Mar 3, 2006, at 10:15 AM, Michael Segel wrote:
On Wednesday 01 March 2006 1:40 pm, you wrote:
Sigh.
I kind of avoided this discussion because I was busy giving a
presentation on
Database Security to the local DB2/Informix user group(s).
null = a null pointer to an object (Java)
NULL = an empty set.
They are two totally different things.
I'm not arguing the semantics of Java null vs SQL NULL. I know they
are different and the only reason people could think that they are
the same is that the JDBC interface maps Java null to SQL NULL in the
interface itself, viz.
spec
ResultSet
getObject
Object getObject(String columnName)
throws SQLException
Gets the value of the designated column in the current row of this
ResultSet object as an Object in the Java programming language.
This method will return the value of the given column as a Java
object. The type of the Java object will be the default Java object
type corresponding to the column's SQL type, following the mapping
for built-in types specified in the JDBC specification.
emphasis mine
If the value is an SQL NULL, the driver returns a Java null.
/emphasis mine
/spec
All I'm talking about in this discussion is the mapping that JDBC
uses in which at the boundary between Java and SQL, null gets morphed
into NULL.
Look at it this way
If you pass in the argument null, you're saying that the object
doesn't exist.
If you pass in a NULL argument, you're saying that the object does
exist,
however its current set of elements is NULL or the empty set.
yeah, yeah, yeah, but not what this discussion concerns.
The only reason I'm even beating a dead horse is that this is moot
point and a
non issue to start with. This has nothing to do with Databases or
the JDBC
API.
Disagree here. The JDBC API is the only thing I'm interested in
discussing.
Here's a different example.
String foo = null;
String bar = ; // Call it a string representation of an empty set
Does foo = bar ?
The point I'm trying to make is that the reference foo is a null
pointer. It
points to nothing, while the reference bar points to a String with no
characters in it.
Does this make sense?
When the JDBC interface transforms SQL NULL into Java null, and some
of the API methods allow passing Java null where the intent is to
store SQL NULL into a column value, then I'm suggesting that where
there is no ambiguity, the interface should treat Java null like the
rest of the interface does.
Specifically, in the case we are discussing, what I'm saying is that
big assumptionassuming that the prepared statement knows that the
parameter you're setting is of type VARCHAR/big assumption, then
setObject(varcharParameter, null) can have the same semantics as
setNull(varcharParameter), setString(varcharParameter, null), or
setObject(varcharParameter, null, Types.VARCHAR). I don't read the
spec as requiring that an unambiguous declaration as to the
programmer's intent must throw an exception.
Why am I making such a big deal about this? So glad you asked.
In my field of expertise, I have to map between SQL and Java domains.
There is a very nice isomorphic mapping between a SQL VARCHAR and
Java String. Similar isomorphic mappings naturally are used between
SQL INTEGER and Java Integer and all the other primitive wrappers.
When writing the code that transfers data from the Java model to the
JDBC interface, I carefully prepare the INSERT statement or UPDATE
statement to contain the appropriate CAST ... AS so that the JDBC
driver knows for each parameter what type to expect.
Now I'm all set to implement the setObject(PreparedStatement ps, int
parameterIndex, Object value). Since the PreparedStatement knows what
type to expect, the implementation of this method is trivial:
ps.setObject(parameterIndex, value).
If the JDBC interface works as you describe, I have to have a very
ugly switch at this lowest level of the code just to put the right
value into the PreparedStatement:
int sqltype = myMetadata.getSQLType(parameterIndex);
if (value == null) {
ps.setNull(parameterIndex, sqltype);
} else {
ps.setObject(parameterIndex, value);
}
And how did I know deep inside my code what myMetadata is? Did I pass
it in as a parameter? Why should this inner loop have to know the
details of what type the parameter is?
Craig
Bernt M. Johnsen wrote On 03/01/06 11:21,:
Craig L Russell wrote (2006-03-01 10:02:58):
I have to say I don't understand the rationale for throwing an
exception here. Looking at the stack trace, I agree with Bernt that
the user is calling setObject(column, null). What I don't agree
with
is that there is any ambiguity as to what the user means.
The setObject javadoc sez:
The JDBC specification specifies a standard mapping from Java
Object
types to SQL types. The given argument will be converted to the
corresponding SQL
Re: Using/Adressing a row number in a SELECT query
Hi Dan,
You are right that taking the requirements as stated, I don't see how
Derby can do it. And I think others had the same opinion.
Looking at the requirement as SELECT * FROM(SELECT ..., [rowid] AS n
FROM ... WHERE ... ) WHERE n BETWEEN $start AND $end; you can't do
it. But in this case, the requirement seems self-defeating. Here's why:
The inner SELECT will do all the work to produce a result, including
the joins, sort, merge, and then the outer SELECT throws away all of
it except for the rows between the $start and $end. As an example, if
you selected all the Ma* in the phone book and sorted on phone
number, you would have thousands of rows to sort and then pick 20 of
them. Not so good in general.
What Derby does to support paging is to allow you to collect the
thousands of rows, sorted, on the server, and then use JDBC to page
through the results. You only do the big inner select once and then
go page through them.
The pseudo-PHP below seems to do the same thing that JDBC paging
does, but IANAPHPE.
Best,
Craig
On Feb 20, 2006, at 12:34 PM, Dan Scott wrote:
Except Sylvain's opening requirement states that he must have this
directly at the SELECT level. He wants this on the fly as the result
of a query, so to use the identity column approach he would need to
dump the results of his query into a temporary table with an identity
column, and then do the select with the corresponding WHERE rowid x
AND rowid y clause to implement the equivalent of a LIMIT...OFFSET.
But Derby doesn't support identity columns in temporary tables, so
this rather complicated approach won't work.
Sylvain, I think your only real option is to handle this outside the
SELECT statement at the application layer. Worst-case scenario, you
implement your pager function by calling fetch() until you reach _x_,
then fetch() and keep rows until you reach _y_.
A pseudo-implementation in PHP (minus error-checking etc) would work
something like:
function pager($stmt, $limit, $offset) {
$counter = 0;
$rows = array();
while ($counter $offset) {
db2_fetch_row($stmt); // simply advances result set pointer to
the next row
$counter++;
}
$counter = 0;
while ($counter $limit) {
$rows[] = db2_fetch_array($stmt); // add the next row to the
results array
$counter++;
}
}
And for a worst-case scenario, it turns out that this isn't really all
that bad: there is almost no network traffic required to simply move
the fetch() pointer ahead by a row when you're not actually retrieving
a row.
Dan
On 2/20/06, Craig L Russell [EMAIL PROTECTED] wrote:
Hi,
I think that most of the databases you might want to use allow you
to define
a column explicitly where the contents are managed by the database
itself
but can be used by the user to imbricate results.
So if you are willing to forego
a pseudo-columnn [sic] (let's say : row) and instead use a real-
column,
then I think the answer is yes. Derby has the MYROW INTEGER
NOT NULL
GENERATED ALWAYS AS IDENTITY construct that generates row values
for you.
Craig
On Feb 20, 2006, at 7:05 AM, Sylvain RICHET wrote:
(few days later...)
[Michael said :]
Again, for what you want, rowId is not going to work
Imagine you have a table. You do a select on the table and you
select
rows 1,
5, 10, 11,13,17 ... How does this help you when you want to
fetch the
first n
rows?
I think you need to go back and rethink your design.
The way i want to use the rowid would be in an imbricated select
SELECT * FROM(SELECT ..., [rowid] AS n FROM ... WHERE ... ) WHERE
n BETWEEN
$start AND $end;
For instance, this is possible with ORACLE, using its ROWNUM
pseudo-column
But certainly not the ROWID pseudo-column : because since rows
can migrate
from location-to-location when they are updated,
ROWID should never be stored an never be counted on to be the
same in any
database.
... that's why Craig said :
If you're using this for logging, and keeping track of which
records you
have already processed, this technique might work.
Since the column is visible and won't change after insert, the same
technique can be used with other databases (e.g. use a sequence on
Oracle...)
[Øystein said :]
I am bit confused about what you need a row number pointer for.
Oracle's RowID and MySql's LIMIT seems like quite different
features.
Sorry, i mentionned the ROWID instead of ROWNUM, which are both
Oracle
pseudo-columns.
So my initial question should have been :
Is DERBY implementing a pseudo-columnn (let's say : row) which
authorize
to do something like :
SELECT * FROM(SELECT ..., [row] AS n FROM ... WHERE ... ) WHERE n
BETWEEN $start AND $end
... in order to get a paging system on the results ?
On 2/19/06, Craig L Russell [EMAIL PROTECTED] wrote:
Hi,
You might consider using a column that the database automatically
increments for each inserted row. Then you could select ranges of
this
column
Re: Using/Adressing a row number in a SELECT query
Hi,I think that most of the databases you might want to use allow you to define a column explicitly where the contents are managed by the database itself but can be used by the user to imbricate results.So if you are willing to forego a pseudo-columnn [sic] (let's say : "row") and instead use a real-column, then I think the answer is yes. Derby has the " MYROW INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY" construct that generates row values for you.CraigOn Feb 20, 2006, at 7:05 AM, Sylvain RICHET wrote:(few days later...) [Michael said :] Again, for what you want, rowId is not going to work Imagine you have a table. You do a select on the table and you select rows 1, 5, 10, 11,13,17 ... How does this help you when you want to fetch the first n rows? I think you need to go back and rethink your design. The way i want to use the rowid would be in an imbricated select SELECT * FROM(SELECT ..., [rowid] AS n FROM ... WHERE ... ) WHERE n BETWEEN $start AND $end; For instance, this is possible with ORACLE, using its ROWNUM pseudo-column But certainly not the ROWID pseudo-column : because since rows can migrate from location-to-location when they are updated, ROWID should never be stored an never be counted on to be the same in any database. ... that's why Craig said : If you're using this for logging, and keeping track of which records you have already processed, this technique might work. Since the column is visible and won't change after insert, the same technique can be used with other databases (e.g. use a sequence on Oracle...) [Øystein said :] I am bit confused about what you need a "row number" pointer for. Oracle's RowID and MySql's LIMIT seems like quite different features. Sorry, i mentionned the ROWID instead of ROWNUM, which are both Oracle pseudo-columns. So my initial question should have been : Is DERBY implementing a pseudo-columnn (let's say : "row") which authorize to do something like : SELECT * FROM(SELECT ..., [row] AS n FROM ... WHERE ... ) WHERE n BETWEEN $start AND $end ... in order to get a paging system on the results ? On 2/19/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi,You might consider using a column that the database automatically increments for each inserted row. Then you could select ranges of this column values.It's not clear from your description whether you know in advance that you want a certain range of rows that were inserted, or exactly what. If you're using this for logging, and keeping track of which records you have already processed, this technique might work. Since the column is visible and won't change after insert, the same technique can be used with other databases (e.g. use a sequence on Oracle...)CraigOn Feb 16, 2006, at 11:47 PM, Sylvain RICHET wrote:Hi everyone, In a selection statement, i would like to get blocks of records. Thus, i need to filter records by a "row number", directly at the SELECT level. It seems that the way to address a row number is not (SQL) standard. (different "proprietary" implementations) In Oracle, there is the "rowid". In MySQL, the "LIMIT" clause can do it. In SQL Server, i think there is the "ROW_NUMBER() OVER..." In DB2 (on AS/400) , there is the "RRN" (Relative Record Number)... What about Derby database ? How is it implemented on this server ? I know i could use Thanks in advance. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: SecurityManager question
Hi Rick, What does the security policy file say with regard to the jar file? That is, what permissions are granted to the code base defined by the jar? As I recall, there are various permissions needed to be granted to the Derby code base (regardless of whether it's autoloaded or loaded by the application) when running with a security manager. Even trivial things like permission to access system properties need to be explicitly granted to the code base. Failures in security often appear to be swallowed because of one of two cases: 1. There is no code to which to report the failure (might be this case) 2. The failure itself is considered a security exposure (file permissions problems are sometimes reported as unable to open file with no further detail as to exactly what file was denied). Apologies in advance if this has already been discussed. Craig On Feb 8, 2006, at 4:37 PM, Rick Hillegas wrote: Hi Myrna, Thanks, the problem does occur if I remove the Derby test harness from the picture. I have attached to JIRA 930 a patch which demonstrates the problem: The Derby drivers fail to autoload when you run under a SecurityManager. However, they do autoload if you don't install a SecurityManager. Hi Dan, Would appreciate any advice which might occur to you given your extensive work with SecurityManagers. Thanks, -Rick Myrna van Lunteren wrote: I am wondering - if you run the test program standalone *with* a SecurityManager, what do you get? Myrna On 2/8/06, *Rick Hillegas* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I am tracking down a problem with autoloading jdbc drivers when running from jar files under the Derby test harness on jdk1.6. Capsule summary: SUCCESS-1 The drivers correctly autoload (from the information in the jar file) when I run my test program standalone (without a SecurityManager) SUCCESS-2 The drivers also correctly autoload if I run the test under the Derby test harness but disable the SecurityManager FAILURE However, the drivers fail to autoload when I run my test program under the default Derby test harness (which sets up a SecurityManager) The vm silently swallows the failure. When I run these test cases with the the java -verbose flag, I see the following: o For the success cases, the autoloading of the driver is logged. o For the failure (Derby test harness) case, around the same place in the log, I see AccessControlException being loaded. This is never loaded in the success cases. So I seem to have some kind of SecurityManager issue here. But what? Later on in the failure case, I successfully load the driver using Class.forName(). What is different in the Derby harness security environment between autoload time and Class.forName() time? How can I instrument vm startup to tease open the swallowed AccessControlException? Would appreciate any advice you may have. Thanks, -Rick Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: OutOfMemoryErrors when testing Derby with DOTS
On Feb 1, 2006, at 8:06 AM, John Embretsen wrote: Craig L Russell wrote: If this test code is representative of the actual application, then the application is in trouble and should be reimplemented in the jdbc area. It is a very well-understood requirement of well- behaved applications that result sets and prepared statements and connections be closed when they are no longer needed. And testing what happens to ill-behaved applications in various configurations doesn't seem to be a good use of anyone's energy. I disagree (obviously, since I have already spent some energy running these tests). At least when such ill-behaved applications may cause serious trouble for other users, which is the case when the Derby Network Server collapses because it runs out of memory (correct me if I'm wrong). I think the only disagreement here is what we think is being tested. If we think we are testing well-behaved applications and trying to make decisions based on the results, then I disagree. If we think we are testing ill-behaved applications and trying to see how well the system under test responds, then I agree. In fact, having an ill-behaved application bring a server down is a useful exercise. And there are improvements that we should make based on the test. Just let's not think that we're evaluating normal behavior. Long term, I don't believe that Derby or any other implementation should try to optimize for applications written without regard for good programming patterns. I agree with Dan's comment on this. For example, I don't regard DERBY-210 as an optimization issue. http://issues.apache.org/jira/browse/DERBY-210 I agree. That said, OutOfMemoryError is unfortunate, but perhaps unavoidable. Does the test succeed, given enough memory? Does closing the result sets and prepared statements change the behavior? More testing is needed to find this out for sure... Looking at DERBY-210, I infer that the DOTS test would eventually fail after all available memory was exhausted. How can Derby know whether you intend to use the result set and prepared statement again, and you actually want to keep them open? Do you want Derby to internally close result sets and prepared statements that it guesses you no longer want? In a large system, wouldn't it be a bug in Derby if Derby closed result sets and prepared statements that the application still wanted? To the last question: I guess so. I'll leave the rest of your questions to someone who has more experience with and knowledge about Derby and database systems in general than I do at the moment ;) I think there are some ongoing discussions about this, e.g. DERBY-210 and DERBY-817. This is the hammer that is making your head hurt. Before you can see if aspirin helps, put down the hammer. Personally, I would prefer a database with a strong enough helmet to withstand such hammer hits. Someone else may find that hammer one day, and hit you again ;) These particular hammers are in an area clearly marked Danger: Use of these hammers may be injurious to your sanity. ;-) That does not necessarily prevent insane carpenters from using them. Let me reiterate the scenario in which multiple users are accessing a Derby Network Server: If a malicious user (yes, they exist) would want to perform, say, a Denial of Service attack against this server, all they have to do is to run such an application! OK, this is not a valid scenario in _all_ environments, but that's not the point I'm trying to make. I agree. Seriously, if you are trying to evaluate different databases' behavior under a simulated application scenario, you should try to duplicate in your tests how the application actually behaves. And if the test is shown to have programming anomalies, and fixing the test informs better behavior in the application, then I'd say the test succeeded. After removing the anomalies in the test, you can see the underlying behavior of the system in various configurations, and have a better way to evaluate alternatives. I agree, to a certain extent. But, my goal of testing Derby is to find potential flaws/weaknesses in Derby, and/or to verify that a certain version of Derby is able to do/handle certain things. In this particular case, DOTS happened to be at my disposal, so I used it. It was not my primary goal to test Derby in a particular application scenario. Again, I want to say that I came into this discussion late, and was originally under the impression that you had an application that you were looking to optimize. I apologize if my comments took everyone off track. Craig -- John Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Finding length of a result set
Hi John, This is a common problem for which there is no good, satisfying solution. If you want an exact answer, you have to run the query to count the results. So it's no surprise to me that running COUNT() with the query takes as long as running the query that returns the results you are interested in. For a complex query, you do all that work on the back end and all you get is a number. And depending on your isolation level, the result is not exact anyway. That is, in read committed mode, if another transaction changes some data that is used by your query, running the same query twice might return different answers, even in the same transaction. And since in your application there is user think time involved, you are probably not even running the queries for subsequent pages in the same transaction. So there really is no rationale for an exact number. So most of the applications I've seen that present the user with a screen full of data at a time forego the N in Now displaying page 1 of N. If you have some idea at the application level about the cardinality of the result you might consider giving the user a hint about how many results are expected. But an exact number isn't technically feasible as far as I know. (Even Google returns Results 1 - 10 of about 7,010,000 (0.46 seconds); this is not based on the back end actually counting anything but using some application heuristic). The two standard object-persistence APIs, JDO and EJB3, both offer direct support for this kind of paging application. They allow you to say skip the first 40 results and give me the next 20 results. And neither of these APIs allows you to get the complete count of results. There's no standard SQL to do what you want. Might be an indication that it's not a straightforward exercise. Craig On Jan 30, 2006, at 11:41 PM, John English wrote: I have a method in a J2EE application which displays the result of a query in a standardised tabular format. The output is presented in pages of 20 results at a time, so I need to know how many rows there are to find the number of pages, and to seek to the start of the correct page. This all works fine, but I have a table with about 13000 rows in it which takes about 40 seconds to complete. I have encapsulated the query in a view, and I then select from this according to various user-supplied criteria (sort order and result filtering). I use the following code to get the number of rows: ResultSet res = stat.executeQuery(); res.last(); int n = res.getRow(); // no. of rows in result res.beforeFirst(); and I then use res.absolute(p) to get to the first row of the current page. The problem is that this seems to take as long as it would take to display all rows of the result. I've also tried using select count(*) from myView but this also takes as long as it would take to process the entire set of rows. That is, the view produces a set of 13000 rows and count(*) then seems to need to read the entire set of rows to find out how big it is. The time it takes drops if the query is filtered, e.g. select * from myView where username='foo'. A query like this might only result in only 100 rows being selected, in which case the time it takes drops accordingly. All I need is 20 rows from the result, and the total number of rows, but it seems that I have to process all 13000 rows just to find out how many there are. Can anyone suggest a better way to find the number of rows in the result other that the ways I've tried? MySQL has a function to tell you the size of a result set directly, but I can't find any JDBC equivalent. TIA, -- John English | mailto:[EMAIL PROTECTED] Senior Lecturer | http://www.it.bton.ac.uk/staff/je School of Computing MIS | Those who don't know their history University of Brighton| are condemned to relive it (Santayana) -- Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: OutOfMemoryErrors when testing Derby with DOTS
Hi Dan,
On Jan 31, 2006, at 12:04 PM, Daniel John Debrunner wrote:
Daniel John Debrunner wrote:
There's no guessing, if the application has a reference to an open
JDBC
object then it is still using it. If it no longer has a reference
to a
open JDBC open then it is no longer using it and Derby must garbage
collect it.
I could have worded that last bit better.
If it no longer has a reference to a open JDBC open then it is no
longer
using it and Derby must allow it to be garbage collected and
release any
of its resources during its garbage collection.
This is possible but can be tricky to implement. You need to be
careful inside Derby to only keep soft references to the result sets
and statements in order to allow the GC to work. And any use of the
soft reference needs to be guarded so as to avoid NPE. And there is
probably work to do when GC notifies you that the reference is going
to be collected.
But even with soft references, you still have the issue of a huge
number of unique statements that have been compiled. And unless you
create a new class loader for each statement, you will have a huge
number of classes in memory. I looked at the DOTS source code and it
is generating a huge number of unique statements that differ only in
the itemID (that is part of the SQL not a parameter).
[So how does Derby clean up the dynamically compiled classes?]
I also verified that the DOTS code only closes statements that
execute successfully and return at least one row of data. So the
failed statements are never closed. And there is no try{...}
finally {...} to close result sets in case of exceptions.
Maybe the fact that this code is now 3 years old since any
maintenance is part of the problem.
Regards,
Craig
Dan.
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
Re: OutOfMemoryErrors when testing Derby with DOTS
Hi,On Jan 27, 2006, at 4:11 PM, Ramandeep Kaur wrote:Hi, As per Stan's mail about prepared statements, I checked the source code for DOTS test case that John ran (ATCJ2.java) to see if prepared statements are getting closed properly. I found that there are few methods in ATCJ2.java where prepared statements are not getting closed. In addition, in doBid() method, pstmt.close(); and pstmt = null; should be added right after the following block. pstmt = conn.prepareStatement(updateBidItemSQL + "'" + itemID + "'");Any reason why itemID is bound to the preparedStatement and not itself passed as a parameter?Generally, preparing statements like this (those that include parameters) just before use has little benefit. The big win is to prepare the statement and then reuse it everywhere. So if you change the updateBidItemSQL to include the itemID as a ? parameter, then pstmt.setInt(3, itemID) you will get the benefit of prepared statements.Craig pstmt.setFloat(1,bidPrice);pstmt.setInt(2,bidCount++);updateCount = pstmt.executeUpdate();DotsConfig.UPDATECOUNT++; Now with patch DERBY-210, there may not be any need to modify DOTS code as all garbage collection will be taken care, but in case you still see problems even after applying patch DERBY-210, you might want to give a try to modify the ATCJ2.java. Also, please increase heap size while running Network Server as well. Thanks, Ramandeep Kaur ([EMAIL PROTECTED]) On 1/27/06, Deepa Remesh [EMAIL PROTECTED] wrote: On 1/27/06, John Embretsen [EMAIL PROTECTED] wrote: Friday, January 27, 2006, 6:14:12 PM, Deepa Remesh wrote: Hi John, After a quick read of your mail, it seems to me some of the OutOfMemoryErrors you are seeing may be because of the leak described in DERBY-210. I have a patch for this attached to the JIRA issue. If it is okay, can you please try re-running the tests after applying this patch? I think it should make some difference in the memory usage. OK, I will give it a try next week, thanks!Thanks. I saw you were running tests with 10.1.2.1. The patch attachedto DERBY-210 is for the trunk. Do you (or anyone else) know what kind of OutOfMemoryError you are seeing with regards to that Jira issue? (Java Heap Space, PermGen space, ...)The OutOfMemoryError seen with DERBY-210 is for Java Heap Space. This happens if an application which uses client driver does not explicitlyclose statements. With 64MB heap space, I get OutOfMemoryError afterexecuting ~950 prepared statements.Deepa Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: OutOfMemoryErrors when testing Derby with DOTS
Hi John, On Jan 30, 2006, at 12:11 PM, John Embretsen wrote: Monday, January 30, 2006, 7:46:42 PM, Craig L Russell wrote: Hi, On Jan 27, 2006, at 4:11 PM, Ramandeep Kaur wrote: Hi, As per Stan's mail about prepared statements, I checked the source code for DOTS test case that John ran (ATCJ2.java) to see if prepared statements are getting closed properly. I found that there are few methods in ATCJ2.java where prepared statements are not getting closed. In addition, in doBid() method, pstmt.close(); and pstmt = null; should be added right after the following block. pstmt = conn.prepareStatement(updateBidItemSQL + ' + itemID + '); Any reason why itemID is bound to the preparedStatement and not itself passed as a parameter? Generally, preparing statements like this (those that include parameters) just before use has little benefit. The big win is to prepare the statement and then reuse it everywhere. So if you change the updateBidItemSQL to include the itemID as a ? parameter, then pstmt.setInt(3, itemID) you will get the benefit of prepared statements. Craig I am fully aware of this rather strange and inefficient use of PreparedStatements in the DOTS test case. As I stated in my first E- mail in this thread: I don't know the rationale behind doing it this way. It may be just sloppy code, or it may be intentional. I was trying to be nice. I'll reiterate my point. If your use of prepared statements is limited to the following pattern: PreparedStatement ps = conn.prepare(savedSQLStatement + + itemID + ); ps.setInt(...); ps.execute(); then you are not taking advantage of prepared statements. Your prepared statement cache is not doing any good at all. This is the hammer that is making your head hurt. Before you can see if aspirin helps, put down the hammer. Craig I guess we have to ask the creators of DOTS for the answer. I have not made any inquiries in this regard as of this time. However, DOTS is a part of the Open Source project called The Linux Test Project, which is a joint project started by SGI™ and maintained by IBM® ( http://ltp.sourceforge.net/ ), so I guess nothing stops us from doing so... However, my main concern right now is that Derby is not robust enough to handle code of this type without running out of memory within a relatively short period of time. I guess that since (even) the DOTS creators wrote such code, other Derby users may be inclined to do so in the future. I would (with help from the Derby community) like to get this issue into the open and (if it is agreed that it is a Derby issue) resolved, and I intend to provide as much information as I can in this regard. Having said that, I would like to point out that Derby is obviously not the only DB with such problems, see Q4 under QA in the DOTS User's Guide: http://ltp.sourceforge.net/dotshowto.php#SEC42 -- John Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Removing Derby tagline
Seems non-controversial. Unlike the "Pure Java Database". :-(+1 to remove the tag line pending Sun's decision.CraigOn Jan 25, 2006, at 3:41 PM, Manjula Kutty wrote:yes..I also agree to remove the tagline --Manjula On 1/25/06, David W. Van Couvering [EMAIL PROTECTED] wrote: We are trying to finalize the work on the Derby logo and getting thisposted to the web site and other places. The one issue still open is the tagline. We all voted +1 for the images that had the tagline "PureJava Database."It's likely that Sun has no issues with using the tagline, but it'staking some time to get this clarified. In the meantime publishing the logo onto our site is being held back.I wanted to see what you all felt about removing the tagline, at leastfor now. We may in the future (potentially the near future if we getfinal clarification from Sun) have a vote to add a tagline (maybe accept submissions just like for the logo itself), but I wanted to know ifthere were any objections to just removing it for now.Thanks,David Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: The text that goes with the Derby logo (Was: Derby logo on the web site)
Hi,I have no issues with the proposed banner.http://issues.apache.org/jira/secure/attachment/12321532/masthead_derby2.pngCraigOn Jan 17, 2006, at 6:31 PM, Samer Kanjo wrote:I liked the positioning of the original tagline. The new tagline seems tofar away from "Apache Derby".-Original Message-From: Jean T. Anderson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 17, 2006 5:55 PMTo: Derby DiscussionSubject: The text that goes with the Derby logo (Was: Derby logo on the website)Jean T. Anderson wrote: I'm resurrecting the topic that tapered off right before the holidays. ... (2) The wording that went with the logo with text at http://issues.apache.org/jira/secure/attachment/12321023/derby_with_text.jpg can't be used as is because of the use of "Java". Dan Debrunner and Craig Russell voiced the strongest concerns about nailing down the text as well as the look of the text. Roger changed the subline from "Pure Java Database" to "Open Source Database":old: http://issues.apache.org/jira/secure/attachment/12321023/derby_with_text.jpgnew: http://issues.apache.org/jira/secure/attachment/12321532/masthead_derby2.pngDoes anybody disagree with his choice of new wording? If so, what do you suggest?Does anybody disagree with the overall look (fonts) used for the text? If so, what do you suggest?If I hear nothing by this Friday, Jan 20, I'll assume this is good to go as is and will ask Roger to create the finals in various sizes. And, Roger, thanks again for all your work on this! -jean Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Select records that are not locked?
On Jan 6, 2006, at 9:30 AM, Bryan Pendleton wrote:Danny wrote: What I was after was a way to build a list of transactions that are available to edit for a user.What I don’t want in the list is any transactions that are currently being edited by another user. I think you should implement this notion of "transaction" within yourapplication, and be careful not to confuse it with the lower-levelDBMS concept of transaction.+1. This is an application-level concept that can be implemented using the techniques below.CraigThat is, in your application, you should have a transaction table,and transactions should have a certain state, and a certain lifecycle,which you can define as appropriate for your application.Then, when a user is editing a transaction, you update the transactionstate in your transaction table to reflect that this transaction iscurrently being edited by this user.And, when you want to build a list of transactions which are notcurrently being edited, you run a select statement which fetchesthe rows from your transaction table which are in the appropriate state.thanks,bryanP.S. Regarding the low-level DBMS transaction, I agree with what othershave already said: keep them short and focused; don't hold them openacross UI think periods. Fetch some data from the database, update thingsas necessary to reflect that a user is currently working with this data,then commit that DBMS transaction. Later, when the user issues somecommand in the UI, use a separate DBMS transaction to return to thoserecords and process them accordingly. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Select records that are not locked?
Hi Danny,On Jan 5, 2006, at 11:14 AM, Danny wrote:Is there a way on a select statement to select all rows that match the whereclause criteria, except for any rows that are locked?I hope not. That's not the way I understand databases are supposed to work. The result of a query is not dependent on the state of the internal exclusion mechanisms.Perhaps what you want is "dirty read" (isolation level 0) where the select statement is not blocked by any locks...CraigDanny GallagherThe Gainer Group6525 The Corners ParkwaySuite 215Norcross Ga, 30092 Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: setObject(idx, bigDecimal, Types.NUMERIC); doesn't work ?
Hi,I asked Lance Anderson, spec lead for JDBC 4.0, about this issue and he replied that he thinks that due to compatibility with existing applications that rely on this behavior, it's unlikely to change.My opinion is that the behavior is surprising, and that most applications that discover that the API with a BigDecimal parameter truncates all the decimals, simply change to the API call that allows you to specify the scale. So my big unfounded claim is that there is no use for the API without the scale parameter taking a BigDecimal parameter with the current behavior. And that changing it has low risk of untoward results.CraigOn Jan 5, 2006, at 5:21 AM, Thomas Dudziak wrote:On 1/4/06, Bernt M. Johnsen [EMAIL PROTECTED] wrote: I was too fast in my conclusions. It is not a bug.setObject(idx, bigDecimal, Types.NUMERIC) is defined to be identicalwith setObject(idx, bigDecimal, Types.NUMERIC, 0) and that's exactlywhat Derby does.If you need decimals, you have to specify scale. E.g.:setObject(idx, new BigDecimal("0."), Type.NUMERIC, 4); Indeed, you're right (though I think this is a design error in JDBCitself). I've changed my source accordingly (using setBigDecimalinstead).Thanks,Tom Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
Re: Select for update, cursors
Hi Danny,In my experience, your proposed implementation strategy generally won't scale past a few users. The reason is that you will have locks held during user think time, which is to be avoided for scalable applications.Alternative things to consider:1. When the first user clicks on a transaction to edit, update the database immediately with the user id and date/time. This lets the second user know that someone else has reserved the right to update. This technique works well for infrequent updates (very commonly used for wikis etc.). You can embellish this technique with soft timeouts (user 1 can still commit changes even after the timeout unless another user has acquired the soft lock).2. Allow as many users to access and update the transaction as you like, but only allow one to succeed. There are several techniques here, such as incrementing a number in the row on each update, and only allowing an update to occur if the user presents the correct update number. Most object-relational mappers use this optimistic locking strategy.The reason for updatable result sets is efficiency and ease of programming where there are a large number of things to update in the same result set. Instead of having to manage two different things (the original result set and the update set) you just manage one updatable result set. But IMHO it's not suitable for the scenario you are talking about with user think time involved.CraigOn Dec 28, 2005, at 8:22 AM, Danny wrote:We are moving from a local database application (1 user to 1 database) to aninstallation that will support a single database on a network (many users on1 database).In looking into select for update, cursors, locking, etc. I have a fewquestions that maybe someone could help me with.Let me preface this with the fact that I am in no way a database programmingexpert.Here is the scenario within the system:1. A user chooses a transaction from a list that they want to edit.2. User clicks edit and all the details of the transaction are displayed inthe gui, the user has the option of editing any of these details.3. User clicks submit and the transaction is updated in the database.Here is where I have gotten so far:1. When the user clicks a transaction from the list and clicks edit, thattransaction is retrieved from the database using a select for update, whichreturns a ResultSet with the following settings"(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_UPDATABLE,ResultSet.HOLD_CURSORS_OVER_COMMIT)2. Second user clicks the same transaction in the list and clicks edit, thattransaction is retrieved using the same query.3. First user changes details in transaction and submits, database updateoccurs through the ResultSet produced from the select from update.4. Second user changes details in transaction, (not the new details createdby user 1, but the original details) and submits, database update occursthrough the ResultSet produced from the select from update..The behavior that I want is:- User 2 to generate some type of exception that I can catch: - Either At the time that they select the transaction in the list that User 1is already editing. OR At the time that User 2 submits the changes when User 1 performed anupdate in the time since User 2 clicked edit to view the details of thetransaction.It seems that what I want is a ResultSet.TYPE_SCROLL_SENSITIVE which (fromwhat I can gather) derby does not support, although I am not sure if thiswould solve my problem.Anyone run into this sort of thing? Any suggestions? I have found somecommentary that the time honored tradition of comparing the last updatetimestamp column is really the best way to go about it, but then why haveupdatable ResultSets at all? ThanksDanny GallagherThe Gainer Group6525 The Corners ParkwaySuite 215Norcross Ga, 30092 Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Incorporating the new derby logo into the web site
Hi Jean,On Dec 21, 2005, at 7:57 PM, Jean T. Anderson wrote:We voted for more than just the one version of the logo with the text. In any event, that specific logo is great for the Derby documentation, but it's too wide for web site display. The screen shot at http://issues.apache.org/jira/secure/attachment/12321496/web-preview-20dec05-2.png doesn't show what it looks like when you expand/reduce the browser window. The image displayed on the web site needs to be more narrow. I'm looking at Susan's variation and I believe it very nicely encapsulates what Roger did in a more narrow space. --I'll post a screenshot of what that looks like. We could of course, simply use the hat without any wording at all: http://issues.apache.org/jira/secure/attachment/12321265/logo_320x200.png . However, that particular image is too large for the web site, so thus requires resizing. I don't believe that resizing it creates a new variation.I agree that resizing it proportionally does not create a new variation of the logo. In other words, we should modify the variations of the logo Roger donated under the ASL as needed to fit a particular purpose. I don't believe that adding text to the logo fundamentally changes it. I don't agree. Removing some legally offending text from the logo might be seen as not changing it, but changing the font and bold characteristics does change it IMHO. If we're filling a box in a web page, it's a logo.Could we ask Roger if he's willing to spend a bit more time putting Apache Derby with the hat into various form factors that can be used for these purposes? Do we have a list of aspect ratios that are needed?Craig Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: [RESULT] [VOTE] Apache Derby logo
"You are in a long passageway with several doors. One door is marked LEGAL. Another is marked TRADEMARK. A third is marked LICENSING. No one who entered any of these doors has been seen since.Your move?"CraigOn Dec 7, 2005, at 3:22 PM, David W. Van Couvering wrote:Let me look into us using the term "Java". It may be that ASF needs to get a license to the trademark, and then it needs to say "Java TM" instead of just "Java".DavidDaniel John Debrunner wrote: Roger Dudler wrote: Hi,Thanks for voting for my submission. That's a great result for me. Congratulations on winning.Is it possible you could provide all the images shown in the showcase asseparate files?And possibly the logo with text modified to not have the "Pure JavaDatabase" tag line? I think Sun Microsystems may have some issue withusing such a term, they protect the Java brand pretty fiercely. Unlesssomeone from Sun points out it is ok.Thanks,Dan.david.vancouvering.vcf Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: ij problem?
Hi Joe,I think your problem is that VARCHAR needs a length, so the ")" in the "user_password VARCHAR)" (at position 161) was unexpected. It expected (20) before the closing ")".Best,CraigOn Dec 6, 2005, at 10:06 AM, Joe Siebenmann wrote:Hi All,I'm trying to create my initial database tables using ij.here's what I get:C:\java -Dij.protocol=jdbc:derby: org.apache.derby.tools.ijij version 10.1ij connect 'c:\db-derby-10.1.2.1-bin\data\NetMgt;create=true';ij run 'c:\mgt\sql\tablex1.sql';ij CREATE TABLE users (user_id INTEGER PRIMARY KEY, first_nameVARCHAR(20), last_name VARCHAR(20), user_level INTEGER, user_nameVARCHAR(20), user_password VARCHAR);ERROR 42X01: Syntax error: Encountered ")" at line 1, column 161.ijCome on! I can't find anything wrong with that, and I can'tfind any more info on the error message in the docs. In factit never mentions 'ERROR 42X01'..No matter how I try to modify the SQL statement, it doesn'tlike it. I did find that if I manually type it in, and leave offthe last column, it doesn't complain..I'm using:C:\java -versionjava version "1.5.0"Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode)And Windows XP.Thanks,Joe Siebenmann __ Yahoo! DSL – Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Apache Derby logo
My vote is for 10. Nice, clean, Escher-esque in the sense of not quite possible but visually interesting.CraigOn Dec 2, 2005, at 1:54 PM, David W. Van Couvering wrote:This is a vote for choosing a logo for Apache Derby.Rules of engagement:- Please vote for one and only one logo.- Respond to both derby-dev and derby-all and put an X to the logo of your choice- Please vote only once. Multiple votes by the same person will be discarded.- The vote will follow DB project guidelines at http://db.apache.org/decisions.html. Anyone can cast a vote, but only committers have binding votes.- Only entries submitted to the JIRA item DERBY-297 will be considered.- The list of logos is officially frozen to those on this ballot. Logos added later will not be considered in the vote.- If no logo has more than 50% of the votes, there will be a runoff vote of the top three vote getters.- Voting closes at 12:00 noon Pacific Standard Time (GMT-8) on Wednesday, December 7=Logo candidates (place an X by your choice).1. [ ] http://issues.apache.org/jira/secure/attachment/12320870/DerbyLogo_Hat_option1.jpg2. [ ] http://issues.apache.org/jira/secure/attachment/12321016/DerbyLogo_Hat_option2.jpg3. [ ]http://issues.apache.org/jira/secure/attachment/12321017/DerbyLogo_Hat_option3.jpg4. [ ]http://issues.apache.org/jira/secure/attachment/12320873/DerbyLogo_text.jpg5. [ ] http://issues.apache.org/jira/secure/attachment/12310607/andrew-derbyhat1.jpg6. [ ]http://issues.apache.org/jira/secure/attachment/12310608/andrew-derbyhat2.jpg7. [ ]http://issues.apache.org/jira/secure/attachment/12310614/andrew-derbyknight1.jpg8. [ ]http://issues.apache.org/jira/secure/attachment/12310615/andrew-derbyknight2.jpg9. [ ]http://issues.apache.org/jira/secure/attachment/20155/derby4.jpg10. [X ] (these all belong together...)http://issues.apache.org/jira/secure/attachment/12321022/derby_logo_only.jpghttp://issues.apache.org/jira/secure/attachment/12321023/derby_with_text.jpghttp://issues.apache.org/jira/secure/attachment/12321055/roger_full_showcase.jpg11. [ ]http://issues.apache.org/jira/secure/attachment/12320752/derbyhatlogo-lettersaligned.pngdavid.vancouvering.vcf Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: Derby with beans and null primitives
Hi,I think your issue is that you are using the wrong representation for the data.If you have nullable columns, map them to Integer.If you have non-nullable columns, map them to int.Otherwise, you will have this issue. If you are stuck with an inflexible object model and an inflexible database schema, then you have to have a policy in place for handling the mismatch. That is, how to store a null Integer into a non-nullable column, and how to store a null column value into an int. Your choices typically are to throw an exception or to represent null as zero. If you choose to represent null as zero you lose information. But this is an application policy choice.CraigOn Nov 29, 2005, at 9:28 PM, Michael McCutcheon wrote:I'm implementing a utility class that populates 'beans' with data from tables in derby. Suppose I have the following 'bean':public class Person{ private String firstName; private String lastName; private int weight; public void setWeight(int inWeight) { this.weight = inWeight; } public int getWeight() { return this.weight; }}I select out of a Person table to get the information to populate this bean.But what happens if weight is nullable in the table?Since you can't put nulls into primitives in Java, how is this handled? This is a real problem because 0 is definately different than no value.Also is there some standard for how JSP's deal with beans with primitive types?How should null primitives be handled in beans like this?ThanksMike Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: Recursive Select for Discussion Forum
Hi Michael,There are two different issues. The one I heard you start asking about is how to select all of the items in a thread. This can be done by selecting all items that match a discussion_id/thread id. The second is how to present them so their relationship to each other is clear. This can be done by making sure that there is a parent_id column that refers to the parent item and returning the parent_id in the selection. I don't see a requirement to perform your selection using parent_id.Bottom line: use a thread_id column to select by; use a parent_id to render showing parent relationship. CraigOn Nov 29, 2005, at 9:36 PM, Michael McCutcheon wrote:Daniel Noll wrote: Michael McCutcheon wrote: snipIf not, are there any ways of handling scenarios like this without having to do a select for each item? I would have done this by having a discussion_id / thread_id column.A discussion generally has properties of its own, so in a full application you would presumably have a discussion or thread table already. Selecting all messages in that discussion then becomes a trivial matter.Daniel But then how do you maintain the hierarchy like javalobby? i.e.:Topic Begin | response response | response | response | response response | response | response responseDon't you have to have a parent_id on each item?It seems like what you are suggesting is a 'flat' type of forum (which I did not think about) where all items have the same parent (for a top-level thread), and are shown sorted by date, not by hierarchy. Is that what you are suggesting?I'm really trying to emulate the behavior of javalobby.Thanks,Mike Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: Concurrency in connections and Threads
Hi Arieh,The situation is complicated if you run multiple statements using the same connection and don't exhaust the ResultSet before returning the connection to the pool.If all you are doing is insert/update/delete then the statements are essentially complete when they are executed. Just watch out for queries. For best portability, a connection should be owned by a thread until all its statements have been completely executed and its result sets closed. Then the connection can be put back into the pool for another thread to use. CraigOn Nov 10, 2005, at 7:33 AM, Arieh Markel wrote:I have autocommit on, so - like you say - I am safe.Thanks,AriehLars Clausen wrote On 11/10/05 08:28,: On Wed, 2005-11-09 at 18:18, Arieh Markel wrote: I am using Derby in 'embedded' mode.A pool of worker threads takes jobs from a queue and followingprocessing populates different tables.So far, in my implementation, all threads shared the same connection.I am wondering whether there are any resulting concurrency issuesthat I may not be aware of.My assumptions are as follows:- the threads are well behaved among themselves relative to (java) concurrency- no two threads update the same database table at any given moment- table lock granularity is what is in place in DerbyBased on that, the same connection (albeit processing different tables)may be used by different threads without creating unnecessary contention.Are those assumptions true ? You should be aware that each connection only has one transaction. Sothe following scenario (serially executed):Turn autocommit offThread 1 executes update of table AThread 2 executes update of table BThread 2 executes a rollbackwould cause the update of table A to be rolled back as well. Ifautocommit is on, you're safe from this particular scenario.-Lars -- Arieh Markel Sun Microsystems Inc.CNS CTO - Advanced Technology 500 Eldorado Blvd. MS UBRM05-169e-mail: [EMAIL PROTECTED] Broomfield, CO 80021http://blogs.sun.com/arieh Phone: (303) 272-8547 x78547 Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Fwd: COUNT queries
Hi,Is the behavior of COUNT(manager) (please see below) specified in SQL?"SELECT COUNT(manager) FROM Employee"Thanks,CraigBegin forwarded message:From: Michael Watzek [EMAIL PROTECTED]Date: November 9, 2005 7:12:45 AM PSTTo: jdo-dev@db.apache.orgSubject: COUNT queriesReply-To: jdo-dev@db.apache.org Hi,does COUNT in JDO consider NULL values? In SQL, NULL values are not considered by COUNT.In JDO, does COUNT consider duplicates? In SQL, duplicates are considered by COUNT.Our testdata has five employees. Four employees have the same manager. One employee does not have a manager.What is the result of the following JDO query: "SELECT COUNT(manager) FROM Employee"?Is the result 4?Regards,Michael-- ---Michael Watzek [EMAIL PROTECTED] Engineering GmbHmailto:[EMAIL PROTECTED] Buelowstr. 66Tel.: ++49/30/235 520 36 10783 Berlin - GermanyFax.: ++49/30/217 520 12 http://www.spree.de/--- Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: Question about using URLClassLoader and Derby
Hi Kathey,The approach looks good. More comments below.On Nov 9, 2005, at 9:14 AM, David W. Van Couvering wrote:Hi, Kathey. At first glance it looks good to me. I'm assuming *all* classes your app needs are available to the from the URL you specify, because you are not specifying a parent classloader when you create it. As I understand it, the only classes that need to be available via the special classloader are the Derby implementation classes and its dependencies. JDBC is a pretty good abstraction layer that uses pass-by-value semantics not pass-by-reference semantics, so as long as you're not using user classes inside your database you should be ok.Also, you'll need to make sure you give the class that runs this code the permission to load classes (I'm not sure exactly how this is done, I just know it's an issue).You might consider providing a helper class as part of the Derby suite that does have the permission. I think it's RuntimePermission("createClassLoader") permission.But you might need other permissions as well since you're playing with URLs; e.g., there are file permissions required to read the jar files referenced by the classpath string. And you should of course call the privileged methods in a doPrivileged block to avoid the entire call stack from having to have the privilege.CraigBut I am no classloader guru. I am forwarding this to folks I know within Sun who have done a *lot* of work within classloaders as part of the app server effort. I'll get back to you with any information I get.DavidKathey Marsden wrote: My goal is:I want to use a specific version of Derby which I ship with my app and Idon't want to interfere with any other derby versions loaded in thesame JVM or have them interfere with me. I am creating a newdatasource in a separate URLClassLoader and using that for creating allmy connections. Are there other things I need to do to meet my goal? I have a feeling it all must be more complex than it looks to me right now.ThanksKathey Below is some code showing what I have done in playing with this so far.Method to load derby in separate loader and create datasource: private static DataSource newDataSource(ClassLoader loader, StringdatabaseName) throws Exception { DataSource ds = (DataSource)loader.loadClass("org.apache.derby.jdbc.EmbeddedDataSource").newInstance(); // setDatabaseName with reflection Class[] argType = {String.class}; String[] args = new String[] {databaseName}; Method sh = ds.getClass().getMethod("setDatabaseName", argType); sh.invoke(ds, args); return ds; } // Calling program . URL[] urls = new URL[]{new URL(derbyJarURLString)}; System.out.println(urls[0].getFile()); ClassLoader loader1 =new URLClassLoader(urls); DataSource ds = newDataSource(loader1,"mydb;create=true"); ds.getConnection(); ... david.vancouvering.vcf Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: I need some advice to choose database for an upcomming job
Michael,On Nov 8, 2005, at 11:18 AM, Michael Segel wrote:Geez, I guess I should have quoted from the spec, rather than the first JDBC tutorial, in which the author's did quote exactly that.This is not to say that junior is wrong. Where do you get off calling people "junior"? I find it offensive.Please try to be professional and cut out the ad hominems.CraigI do believe him that the 3.0 spec probably does say that. This is a problem that occurs when people don't think about their design and merely regurgitate what they've read. Or that they rush a design without thinking about it first.As pointed out, JDBC 4.0 spec does seem to correct this.But hey, what do I know. I'm not paid to play here. ;-)-G-- Michael SegelPrincipal MSCC Craig RussellArchitect, Sun Java Enterprise System http://java.sun.com/products/jdo408 276-5638 mailto:[EMAIL PROTECTED]P.S. A good JDO? O, Gasp!
Re: I need some advice to choose database for an upcomming job
Often, databases are installed in a web server so they are able to be shared among multiple web applications. Depending on the web server, installation might require the server to be bounced to take effect, although many servers can dynamically add resources. The referenced article calls this Casual Integration and Enterprise Integration. If the Derby database is intended only for use by a specific web application (not shared) I don't believe that the web server is even aware of its use, and therefore no installation, configuration, or special treatment of the database is needed. The article refers to this as Prototype Integration. To the web server, the application is simply accessing files, so the only thing that's needed is to configure the application for deployment such that file access is permitted. As far as I know, the only thing to watch out for is class loader conflicts. To avoid possible conflicts among multiple applications using Derby, the non-delegate property of the application should be used. This has the effect of loading the entire Derby code base into the application. For efficiency, if multiple applications are going to use Derby, it might be a good idea to use delegate and share the Derby code, understanding that sharing the code has more requirements (you need to make sure that the different applications can use the same version of Derby). Craig On Oct 30, 2005, at 10:06 AM, Jean T. Anderson wrote: Legolas Woodland wrote: Thank you for references I read the article of embeding Derby into Tomcat but in my case i have no full access to server to stop tomcat or install derby into the server. I thought Embeding means no installation requirement. is there any way that i include some derby jar files with my web application (into lib folder) and use it as embeded DB server ? Check out Lance Bader's developerWorks article Integrate Cloudscape Version 10 or Derby with Tomcat: http://www.ibm.com/developerworks/db2/library/techarticle/ dm-0508bader/index.html His prototype integration option doesn't require touching the Tomcat configuration. While his instructions have you stop/start the tomcat server, I don't know if this is strictly necessary to add derby to your existing web application. Does anyone on this list know for sure? -jean Thank you. On 10/29/05, *Jean T. Anderson* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Legolas Woodland wrote: Hi Thank you for reading my post I should design and implement an application which is going to run on tomcat 5.5 and Database can be one of derby ,sqlServer , Mysql. Problem is that this application should be able to have about 15 -20Transaction in 1 second .They have no extra power servers , just an ordinary hosting plan. my question is : which of this database is better to choose ? i thought that derby could be better because it can be embeded into my application . can derby carry out 15-20 transacion in 1 secod ?is it feasible with using DAO pattern and plain JDBC ,or it need some other requirement ? I have Struts and mysql experience I learned derby but i did not use it yet. before they ask me about implementing this project they used PHP+Mysql and it seems that that application Hangs on +10 hits per second each hit had some Insert one update and 2 select at least. Dan Debrunner's Introducing Apache Derby presentation from ApacheCon US last November might have some helpful info for you. You can download it from http://db.apache.org/derby/binaries/djd_derby_intro.pdf . A Guidelines section starts on slide 19. Slide 24 lists 100-500 updates per second -- but, of course, your actual performance will depend on the complexity of your transactions. Also you might be interested in an article Stan Bradbury contributed yesterday that shows a way to embed Derby in Tomcat 5.5. You can find it here: http://db.apache.org/derby/integrate/ DerbyTomcat5512JPetStor.html http://db.apache.org/derby/integrate/ DerbyTomcat5512JPetStor.html I hope this helps. regards, -jean
Re: [Java exception: 'loader,constraints violated when linking,org/apache/derby/iapi/store/access/StaticCompiledOpenConglomInfo,class: java.lang.LinkageError']
Hi, In my experience, LinkageError is a symptom of a build issue or a classpath issue. It usually means that the methods defined in an interface are not defined in a class that claims to implement that interface. For example, if you build your application using version 3.0 of some library and then execute the program with version 4.0 of the library, where a method of the library has changed its signature. Or build with version 4.0 and execute with 3.0 that doesn't implement a method in the interface. A classpath issue might be if you have different versions of Derby available in Tomcat and some of the classes are from one version of Derby and some others from a different version. NoPutResultSet implements ResultSet. What you're describing would happen if you used a JDBC 3.0 ResultSet with a version of Derby that didn't support the JDBC 3.0 methods. But I don't know how that could happen. You mentioned that I've started throwing...LinkageErrors. What changed in your environment between working ok and throwing Errors? Regards, Craig On Oct 30, 2005, at 6:06 AM, Simon J Whittle wrote: Dear All, This is my first post to this list so my apologies for any conventions/rules I've inadvertently broken :-) My situation is as follows: there is a commercial application called BlackBoard which is used by universities to provide learning resources to students, it's built upon Apache Tomcat and allows 3rd parties to develop Building Blocks (separate tomcat webapps) which can be integrated into the main BlackBoard application. As part of my Building Block I have a servlet which creates a database (using the Cloudscape 10.0 library), and despite a few hic-ups on the learning curve it uses Java commands to create the database and it seemed to work fine. However I've started throwing some bizarre LinkageError's (see subject) when querying the database, and so I thought I'd try the latest (10.1.1.0) Derby library except this time I get SQL Exception: Java exception: 'loader constraints violated when linkingorg/apache/derby/iapi/sql/execute/NoPutResultSet class: java.lang.LinkageError' when I'm actually creating the tables and inserting a value for the first time (this didn't cause any problems with the Cloudscape library). If anybody has encountered anything like this before then I'd appreciate any assistance - is it a bug or something I'm doing wrong on my part? Is there a workaround? I searched http://issues.apache.org/jira for LinkageError but nothing seemed to be directly related. Thanks in anticipation. Simon Whittle
Re: [Fwd: Re: Are you happy with Derby?]
I am not a lawyer, but I believe that Michael's interpretation is way off base. On Oct 26, 2005, at 10:50 PM, Michael J. Segel wrote: On Thursday 27 October 2005 00:00, David W. Van Couvering wrote: Michael J. Segel wrote: On Wednesday 26 October 2005 17:44, Daniel John Debrunner wrote: Raji Sridar wrote: Hi Michael, Your opinion was very encouraging - I also built a prototype based on Derby. I am happy to say, that our management has almost decided on Derby, subject to legal approval for the licensing aspects. Yeah thats the kicker. I'm not a lawyer, so take what I say with a grain of salt. If you use Derby embedded in your app, you have to also ship a copy of the derby source code with your app. Note: If your app is actually a modification to Derby, then you have to publish the source code of your app. And this is where it gets tricky. Huh? It sounds like you are talking about Gnu Public License, not Apache 2.0 license. I'm not a lawyer either, and you do need to check the license, but as I understand it, you are free to redistribute binaries as you see fit, and source code of neither Derby nor your application need to be provided. You can also take Derby and modify it as your needs fit and are free to either put these changes back into Apache Derby or not. David Errr yeah, probably. I was typing this as I was watching the SOX rule! Yeah, I went back and read Apache 2.0. Very interesting reading. And no, its not compatible with GPL. (Again talk to a lawyer. ;-) True, but who cares? The Apache license is much more liberal than GPL or even LGPL. Essentially you are correct. All you need to include is the notice that you used Apache code in your product and follow the instructions and you're free to do with it what you want. If you include notices then you need to include the notice that you used Apache code. This would also explain why I see so many folks from IBM and SUN here. ;-) (TANSTAAFL still applies. Hopefully McNeally, and Mills remember this ) So essentially, anything is fair game. The only draw back is that if you wanted to do some cool work, any corporation could just take your IP and apply it in their own products. Not at all. You are free to license the derived work under any license you choose. For example, if one were to create a really cool method for optimizing query performance and adds it to Derby, IBM or Oracle could take that and use it in their other products. No, there is no requirement that you even publish your changes. The only way to protect against that would be to create your own distribution tree and as each new version of Derby that comes out, you would have to merge it against your tree. If you want to use Derby with proprietary and non-Apache license terms, of course you would create a distribution that includes your modifications. But you could choose the timing of when you re- synchronized with the Derby distribution. Bottom line. Its best to use Derby, as it, and if you wanted to extend Derby, write your own Java Database. ;-) I don't know where this conclusion came from. The Apache license is very liberal for developers who just want to use Derby as is as well as for developers who want to change it just a bit, as well as for developers who want to radically change some part of it. I'd really suggest a competent legal authority review this with you. Craig Interesting -- Michael Segel Principal MSCC (312) 952-8175
