Re: Binding a char to PreparedStatement

Hi Andy,On Jul 20, 2005, at 10:24 AM, Andy Jefferson wrote:Hi Craig, I'm also talking about the jdbc-type (or to be specificjavax.sql.Types). Sothe JDO impl should always take JDBC Types.DOUBLE when the user hasa Javadouble field? Many JDBC drivers *don't* provide a type mapping forTypes.DOUBLE (ma

Re: PMF "DetachOnClose"

Hi Andy,This is still unresolved. :-(There are some technical issues with detach on close and its alternative, detachAll() that detaches everything in the cache. I'm working on it...CraigOn Jul 20, 2005, at 10:26 AM, Andy Jefferson wrote:Hi Craig,the most recent spec I have has reference to a PM.se

equivalent mappings of join condition?

Hi, Are the following mappings equivalent? They differ in the placement of the element. Mapping 1: column="DATASTORE_IDENTITY"/> column="DISCRIMINATOR"/>

Re: Binding a char to PreparedStatement

Hi Craig, > > I'm also talking about the jdbc-type (or to be specific > > javax.sql.Types). So > > the JDO impl should always take JDBC Types.DOUBLE when the user has > > a Java > > double field? Many JDBC drivers *don't* provide a type mapping for > > Types.DOUBLE (many don't provide support for

PMF "DetachOnClose"

Hi Craig, the most recent spec I have has reference to a PM.setDetachOnClose(boolean) method (section 12.6.8). This isn't in the API20 project. It also refers to a property ... which I think was going to be "javax.jdo.option.DetachOnClose". Can you clarify what the JDO impl can plan to use ?, a

Re: Binding a char to PreparedStatement

Hi Andy,On Jul 20, 2005, at 9:57 AM, Andy Jefferson wrote:Well in the case of a char it is, but in the case of a java double forexample ? It all depends on the RDBMS. Some RDBMS support DOUBLE, someDECIMAL, some NUMERIC, some have other types ... This is the jdbc-type ("generic sql type"), not the

Re: Binding a char to PreparedStatement

> > Well in the case of a char it is, but in the case of a java double for > > example ? It all depends on the RDBMS. Some RDBMS support DOUBLE, some > > DECIMAL, some NUMERIC, some have other types ... > > This is the jdbc-type ("generic sql type"), not the sql-type we're > talking about (there is

Re: Binding a char to PreparedStatement

Hi Andy,On Jul 20, 2005, at 9:40 AM, Andy Jefferson wrote:"The jdbc-type attribute declares the type of the column in thedatabase. This type is defaulted based on the type of the fieldbeing mapped."Does this mean, that an implementation may choose for an default? That was not the intent. The intent

Re: Binding a char to PreparedStatement

> > "The jdbc-type attribute declares the type of the column in the > > database. This type is defaulted based on the type of the field > > being mapped." > > > > Does this mean, that an implementation may choose for an default? > > That was not the intent. The intent was that the JDBC type would b

Re: Binding a char to PreparedStatement

Hi,On Jul 20, 2005, at 8:49 AM, Michael Watzek wrote:Hi Andy,I extended the test program to make objects persistent using JPOX in addition to the JDBC test I described below:There is a persistence capable class having a field of type "char".There is a table having a single column of type "CHAR(1)".

Re: Binding a char to PreparedStatement

Hi Andy, I extended the test program to make objects persistent using JPOX in addition to the JDBC test I described below: There is a persistence capable class having a field of type "char". There is a table having a single column of type "CHAR(1)". The orm metadata for this class specifies a

Re: JDO API compability with JDK 1.3

> You are right. We have to mention java.util.Currency in order to > support it, and those classes we need to compile under 1.4. > I'd like to get feedback from others on this as well. Craig, That's what we're doing with JPOX. I can't see a better way -- Andy

Re: JDO API compability with JDK 1.3

Hi Michael,You are right. We have to mention java.util.Currency in order to support it, and those classes we need to compile under 1.4. The other way to handle it would be to have files that only compile under 1.4 and have a callout to those programs if the runtime environment is 1.4.I'd like to ge

Patch for review: add method to return the root list to CompanyModelReader

Hi, attached you find a patch adding a new method getRootList to the CompanyModelReader. It expects to find a bean called root and having the type List in the testdata xml. The method returns the list. I changed the CompletenessTest and the query test superclass to make use of the new method.

Re: JDO API compability with JDK 1.3

Hi Craig, this looks good. I have a question what kind of JDK 1.3 compatibility do we want to support? Your change allows to run an application against a api20.jar using JDK 1.3. But we still require JDK 1.4 to build the api20.jar, meaning to compile the javax.jdo sources. I think this is not

Re: JDOHelper patch

Hi Craig, this looks good! It makes JDOHelper.getPMF much easier. Regards Michael Hi, This patch fixes the exception thrown in case of a missing method. It also requires a JDO implementation to implement the static getPersistenceManagerFactory(Map props) method. And it adds two test cases

Re: Binding a char to PreparedStatement

Hi Michael, > we have a lot of derby errors "ERROR 22001: A truncation error was > encountered trying to shrink CHAR 'XXX' to length 1." I've never seen one of these in our testcases, so we've got some difference in how the TCK is specifying things and how we've done it. > I analysed the proble

Re: jdoPreClear on deleted instances

The below may look like an afirmative phrase, but it should be seem as of "please shoot on me". Can you help me on this? Quoting [EMAIL PROTECTED]: > > Thx, > > The NullPointException is happening on a collection field, which is lazy > loaded > by JPOX, but at this time, the fie