You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Andy Jefferson <an...@jpox.org> on 2005/07/31 19:48:57 UTC
JIRA JDO-68
The issue about "A truncation error was encountered trying to shrink CHAR
'65535' to length 1" should now be fixed with latest JPOX. JPOX CVS now uses
default "jdbc-type" as per the most recent JDO spec. In particular for this
error, when the java type is Character/char the jdbc-type chosen will be
CHAR(1) (where the RDBMS supports it, which Derby does).
Test errors/failures previously were
61 for application-id, 60 for datastore-id.
Now we have
51 for application-id, 46 for datastore-id.
and moreover, of the remaining errors there are 15 for application-id, and 11
for datastore-id giving "SQL Exception: Invalid character string format for
type INTEGER". This occurs where the schema has been defined with an INTEGER
column to represent a Character/char(/String) java type (maybe to allow for
previous JPOX behaviour) and implies that the schema needs some updates to
match the default jdbc-type expected by the JDO2 spec (and now also by JPOX).
Schema where column is INTEGER but should be CHAR(1)
FieldsOfCharacter : table FIELDSOFCHARACTER has INTEGER columns
FieldsOfPrimitivechar : table FIELDSOFPRIMITIVECHAR has INTEGER columns
Schema where column is INTEGER but should be VARCHAR(...)
HashMapStringKeyCollections, HashMapStringValueCollections,
MapStringKeyCollections, MapStringValueCollections,
TreeMapStringKeyCollections, TreeMapStringValueCollections : join tables have
the key as INTEGER instead of VARCHAR
There may be others of the same nature that I've not listed, just wanted to
give a head start on fixing the schema.
Also, this change may affect other JIRA issues, but sadly
"http://issues.apache.org" is about as unresponsive a server as I've ever
come across, so we'll have to leave that for others to work out ;-)
--
Andy
Re: How to get started on JDO
Posted by Niclas Hedhman <he...@gmail.com>.
On Thursday 04 August 2005 06:47, Craig Russell wrote:
> This is a new project to Apache and we're trying to attract new
> committers. If you don't find what you're looking for, or have any
> other comments, please let us know.
The shear speed of this project makes it somewhat harder to "catch up on" as a
aspiring contributor.
I suggest that the core team take a moment and list down these "follow-on
directions" that you can see. This might create a bit of "Ah! I can do that."
and knowing that 36 hours later someone in the core team has already grabbed
it and forging ahead.
To me it is not totally clear the scope of this project. One side says it is
about TCK development and the RI is over at jpox.org (what was the reason
again?), yet Maven support seems to be covered over here. I can think of
additional tools for Eclipse, but not entirely sure if those are valid for
this project (also unsure if they exist elsewhere);
* Enhancer integration into Eclipse.
* Schema generator in Eclipse.
* Graphical mapping of value objects to existing databases.
* Form editing of jdo directives.
* Validation that PC classes are properly compiled and jarred.
* Those little "badges" on file icons to indicate PC classes.
I can also imagine documentation tools, that generates graphical view of the
the valueobject <-> database relationships, as well as pure RDBMS
relationships. Would be nice if that was integrated with the Javadocs of the
same sources.
My 2 cents.
Cheers
Niclas
Re: How to get started on JDO
Posted by Craig Russell <Cr...@Sun.COM>.
Hi Karan,
This is a new project to Apache and we're trying to attract new
committers. If you don't find what you're looking for, or have any
other comments, please let us know.
Thanks,
Craig
On Aug 3, 2005, at 11:42 AM, Karan Malhi wrote:
> Thanks Craig,
> I quickly looked through the wiki, i guess i need to spend some
> more time
> with it to properly understand what is going on. I am not sure
> about the
> follow-on directions yet, so cannot comment on what specific areas
> of JDO i
> would be interested in. I need to figure out what the specific
> areas are .
> Will read the spec and the wiki carefully and then will get back to
> you as
> to what i am interested in.
> Regards
>
> On 8/2/05, Craig Russell <Cr...@sun.com> wrote:
>
>>
>> Hi Karan,
>> On Jul 31, 2005, at 11:33 AM, Karan Malhi wrote:
>>
>> Can anybody give me a starting point to start contributing ?
>>
>> I think that the best thing for you to do is to look at the wiki
>> pages and
>> get a feel for the project activities. Right now, we are building
>> spec-compliance tests for implementations to prove that they are
>> valid JDOimplementations. This is the TCK activity, mostly focused
>> on object
>> relational mapping.
>>
>> What are your interests in JDO? There are a number of follow-on
>> directions that might interest you.
>>
>> Best regards,
>>
>> Craig
>>
>>
>>
>> Craig Russell
>>
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>>
>> 408 276-5638 mailto:Craig.Russell@sun.com <Cr...@sun.com>
>>
>> P.S. A good JDO? O, Gasp!
>>
>>
>>
>>
>
>
> --
> Karan Malhi
>
> "Playfully doing something difficult, whether useful or not, that is
> hacking." -- Richard Stallman
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: How to get started on JDO
Posted by Karan Malhi <ka...@gmail.com>.
Thanks Craig,
I quickly looked through the wiki, i guess i need to spend some more time
with it to properly understand what is going on. I am not sure about the
follow-on directions yet, so cannot comment on what specific areas of JDO i
would be interested in. I need to figure out what the specific areas are .
Will read the spec and the wiki carefully and then will get back to you as
to what i am interested in.
Regards
On 8/2/05, Craig Russell <Cr...@sun.com> wrote:
>
> Hi Karan,
> On Jul 31, 2005, at 11:33 AM, Karan Malhi wrote:
>
> Can anybody give me a starting point to start contributing ?
>
> I think that the best thing for you to do is to look at the wiki pages and
> get a feel for the project activities. Right now, we are building
> spec-compliance tests for implementations to prove that they are valid JDOimplementations. This is the TCK activity, mostly focused on object
> relational mapping.
>
> What are your interests in JDO? There are a number of follow-on
> directions that might interest you.
>
> Best regards,
>
> Craig
>
>
>
> Craig Russell
>
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>
> 408 276-5638 mailto:Craig.Russell@sun.com <Cr...@sun.com>
>
> P.S. A good JDO? O, Gasp!
>
>
>
--
Karan Malhi
"Playfully doing something difficult, whether useful or not, that is
hacking." -- Richard Stallman
Re: How to get started on JDO
Posted by Craig Russell <Cr...@Sun.COM>.
Hi Karan,
On Jul 31, 2005, at 11:33 AM, Karan Malhi wrote:
> Can anybody give me a starting point to start contributing ?
>
I think that the best thing for you to do is to look at the wiki
pages and get a feel for the project activities. Right now, we are
building spec-compliance tests for implementations to prove that they
are valid JDO implementations. This is the TCK activity, mostly
focused on object relational mapping.
What are your interests in JDO? There are a number of follow-on
directions that might interest you.
Best regards,
Craig
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
How to get started on JDO
Posted by Karan Malhi <ka...@gmail.com>.
Can anybody give me a starting point to start contributing ?
Re: JIRA JDO-68
Posted by Michelle Caisse <Mi...@Sun.COM>.
Hi again Michael,
To further clarify, I agree that we want to leave the fld_char and
fld_Character fields of AllTypes as INTEGER and change the orm to
specify the jdbc-type. However, I think that Andy was correct in saying
that the tables FIELDSOFCHARACTER and FIELDSOFPRIMITIVECHAR should have
CHAR(1) columns. I already made that change. I haven't looked at
PCPointSingleFieldChar, so I have no opinion about that one.
-- Michelle
Michael Watzek wrote:
> Hi Michelle, Andy,
>
> sorry I did not reply earlier.
>
> I talked to Craig about this issue yesterday. We agreed on leaving
> tables "FIELDSOFCHARACTER", "FIELDSOFPRIMITIVECHAR", and
> "PCPointSingleFieldChar" as they are keeping the INTEGER columns.
>
> The rationale is that pc class instances mapped to those tables have
> character values which are initialized based on numerical values
> rather than character values, e.g. "Character.MAX_VALUE",
> "Character.MIN_VALUE", or
> "System.currentTimeMillis()%Character.MAX_VALUE".
>
> For this reason, we decided to adapt the ORM metadata rather than to
> adapt the schema: <field> elements corresponding to fields of type
> "char" or "java.lang.Character" will have "jdbc-type" attributes, e.g.
>
> <class name="PCPointSingleFieldPrimitivechar"
> table="PCPointSingleFieldChar">
> <field name="id" primary-key="true">
> <column name="ID" jdbc-type="INTEGER"/>
> </field>
> ...
> </class>
>
> For pc classes like "HashtableStringValueCollections" (etc.) the story
> is slightly different:
>
> They have several fields of type "java.util.Map" where (sometimes)
> keys are FCOs (e.g. SimpleClass instances) and values are strings. The
> types of keys and values differ and can be derived by the classname.
>
> Each of these fields is mapped to a separate (join) table having join
> columns, key columns, value columns, and index columns. In the current
> schema, all of these columns have type "INTEGER".
>
> This is a bug: Keys and values of type "java.lang.String" must be
> mapped to columns of type "VARCHAR". Furthermore, join tables which
> are mapped by fields of maps or sets do not have index columns.
> Question: Do we have to distinguish bewteen sorted maps/sets vs.
> non-sorted maps/sets?
>
> I'll prepare two patches today fixing these issues - one for each
> identity type.
>
> Regards,
> Michael
>
>> Hi Andy,
>>
>> This is really good, a big improvement in the error count.
>>
>> Andy Jefferson wrote:
>>
>>> ...
>>> Schema where column is INTEGER but should be CHAR(1)
>>> FieldsOfCharacter : table FIELDSOFCHARACTER has INTEGER columns
>>> FieldsOfPrimitivechar : table FIELDSOFPRIMITIVECHAR has INTEGER columns
>>>
>>>
>> I am fixing these.
>>
>>> Schema where column is INTEGER but should be VARCHAR(...)
>>> HashMapStringKeyCollections, HashMapStringValueCollections,
>>> MapStringKeyCollections, MapStringValueCollections,
>>> TreeMapStringKeyCollections, TreeMapStringValueCollections : join
>>> tables have the key as INTEGER instead of VARCHAR
>>>
>>>
>> I agree that the KEYVAL columns in *StringKeyCollections and the
>> VALUEVAL columns of *StringValueCollections should be VARCHAR. We
>> have some other fixes we need to make to the mapping for these, so
>> I'll make these changes with those.
>>
>>> Also, this change may affect other JIRA issues, but sadly
>>> "http://issues.apache.org" is about as unresponsive a server as I've
>>> ever come across, so we'll have to leave that for others to work out
>>> ;-)
>>>
>>>
>>>
>> The server seems to have come to life again. I will update the
>> issues soon.
>>
>> -- Michelle
>
>
>
Re: JIRA JDO-68
Posted by Michael Watzek <mw...@spree.de>.
Hi Andy,
thanks for the info!
I'll check later why the exception is not thrown on my side. Having
fixed the ORM metadata, the test passes. Thus, this is not an urgent
issue. I'll further investigate when there is some time left.
Regards,
Michael
>>The message reads as if the exception is thrown during execution of
>>SchemaTool. I'm not sure if SchemaTool if executed running TCK because
>>TCK assumes there is an existing schema in DB. These are JPOX parameters
>>that TCK specifies in file "jdori.properties":
>
>
> Hi Michael,
>
> SchemaTool is simply a wrapper to "JPOX runtime" but with autoCreateSchema,
> autoCreateConstraints set to true and the metadata files loaded up
> immediately (code reuse !). They both load the metadata and the load of
> metadata is throwing the exception - so it is the same with either. The error
> at runtime is this :-
>
> org.jpox.metadata.InvalidMetaDataException: Class org.jpox.test.Simple has
> field org.jpox.test.Simple.name2 declared in MetaData, but this field doesnt
> exist in the class!
> at org.jpox.metadata.ClassMetaData.populate(ClassMetaData.java:693)
> at
> org.jpox.metadata.MetaDataManager.populateClassesInFile(MetaDataManager.java:636)
> at
> org.jpox.metadata.MetaDataManager.getFileMetaDataForUrlContainingClass(MetaDataManager.java:1186)
> ...
> at
> org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:952)
> at
> org.jpox.AbstractPersistenceManager.makePersistent(AbstractPersistenceManager.java:1050)
>
>
> Why you don't see this must be down to your exact metadata files and where you
> have the classes etc.
>
--
-------------------------------------------------------------------
Michael Watzek Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------
Re: JIRA JDO-68
Posted by Andy Jefferson <an...@jpox.org>.
> The message reads as if the exception is thrown during execution of
> SchemaTool. I'm not sure if SchemaTool if executed running TCK because
> TCK assumes there is an existing schema in DB. These are JPOX parameters
> that TCK specifies in file "jdori.properties":
Hi Michael,
SchemaTool is simply a wrapper to "JPOX runtime" but with autoCreateSchema,
autoCreateConstraints set to true and the metadata files loaded up
immediately (code reuse !). They both load the metadata and the load of
metadata is throwing the exception - so it is the same with either. The error
at runtime is this :-
org.jpox.metadata.InvalidMetaDataException: Class org.jpox.test.Simple has
field org.jpox.test.Simple.name2 declared in MetaData, but this field doesnt
exist in the class!
at org.jpox.metadata.ClassMetaData.populate(ClassMetaData.java:693)
at
org.jpox.metadata.MetaDataManager.populateClassesInFile(MetaDataManager.java:636)
at
org.jpox.metadata.MetaDataManager.getFileMetaDataForUrlContainingClass(MetaDataManager.java:1186)
...
at
org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:952)
at
org.jpox.AbstractPersistenceManager.makePersistent(AbstractPersistenceManager.java:1050)
Why you don't see this must be down to your exact metadata files and where you
have the classes etc.
--
Andy
Java Persistent Objects - JPOX
Re: JIRA JDO-68
Posted by Michael Watzek <mw...@spree.de>.
Hi Andy,
>>One question: JPOX does not complain if the ORM metadata for a class
>>specifies fields which do not exist in that class. Would it be an option
>>to throw a JDOFatalUserException("ORM metadata of class XXX specifies
>>column mapping for field YYY. This field does not exist in the class.")
>>in this case?
>
>
> Hi Michael,
>
> Well in my tests JPOX *does* complain about situations of incorrectly named
> fields. Here's an example
>
> public class Simple
> {
> String name;
> }
>
> <jdo>
> <package name="org.jpox.test">
> <class name="Simple">
> <field name="name"/>
> </class>
> </package>
> </jdo>
>
> <orm>
> <package name="org.jpox.test">
> <class name="Simple">
> <field name="name2"/>
> </class>
> </package>
> </orm>
>
> and it gives "An exception was thrown during the operation of SchemaTool.
> Please refer to the log for full details. The following may help :
> org.jpox.metadata.InvalidMetaDataException: Class org.jpox.test.Simple has
> field org.jpox.test.Simple.name2 declared in MetaData, but this field doesnt
> exist in the class!"
The message reads as if the exception is thrown during execution of
SchemaTool. I'm not sure if SchemaTool if executed running TCK because
TCK assumes there is an existing schema in DB. These are JPOX parameters
that TCK specifies in file "jdori.properties":
org.jpox.validateTables=false
org.jpox.validateConstraints=false
org.jpox.autoCreateSchema=false
org.jpox.autoCreateTables=false
org.jpox.autoCreateConstraints=false
org.jpox.autoCreateColumns=false
org.jpox.rdbms.CheckExistTablesOrViews=false
Are these adjustments right?
Regards,
Michael
--
-------------------------------------------------------------------
Michael Watzek Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------
Re: JIRA JDO-68
Posted by Andy Jefferson <an...@jpox.org>.
> One question: JPOX does not complain if the ORM metadata for a class
> specifies fields which do not exist in that class. Would it be an option
> to throw a JDOFatalUserException("ORM metadata of class XXX specifies
> column mapping for field YYY. This field does not exist in the class.")
> in this case?
Hi Michael,
Well in my tests JPOX *does* complain about situations of incorrectly named
fields. Here's an example
public class Simple
{
String name;
}
<jdo>
<package name="org.jpox.test">
<class name="Simple">
<field name="name"/>
</class>
</package>
</jdo>
<orm>
<package name="org.jpox.test">
<class name="Simple">
<field name="name2"/>
</class>
</package>
</orm>
and it gives "An exception was thrown during the operation of SchemaTool.
Please refer to the log for full details. The following may help :
org.jpox.metadata.InvalidMetaDataException: Class org.jpox.test.Simple has
field org.jpox.test.Simple.name2 declared in MetaData, but this field doesnt
exist in the class!"
--
Andy
Re: JIRA JDO-68
Posted by Michael Watzek <mw...@spree.de>.
Hi Andy,
I found the problem:
I had prepared the ORM metadata for class "FieldsOfCharacter" in another
local workspace. Mistakenly, I made a stupid copy/paste mistake copying
wrong metadata for class "FieldsOfCharacter" into my current workspace:
I copied the contents of file "FieldsOfPrimitivechar-derby.orm" to file
"FieldsOfCharacter-derby.orm".
Fixing this, test "TestFieldsOfCharacter" successfully passes.
One question: JPOX does not complain if the ORM metadata for a class
specifies fields which do not exist in that class. Would it be an option
to throw a JDOFatalUserException("ORM metadata of class XXX specifies
column mapping for field YYY. This field does not exist in the class.")
in this case?
Regards,
Michael
>>I changed the column types of table "FIELDSOFCHARACTER" back to INTEGER.
>>I also changed the ORM metadata for class "FieldsOfCharacter", e.g.
>
>
>>I'm using JPOX nightly build 2005-08-01. Can you please check and verify
>>if JPOX calls "PrepraredStatement.setString" for the case above?
>
>
> Hi Michael,
>
> It's not in SVN. When it's in SVN then I'll have a look.
>
> For the record on the issue of CHAR(1) or INTEGER, I'm not too fussed whether
> we have CHAR(1), or INTEGER or whatever - all I want is consistent metadata
> and schema so it's a fair test.
>
--
-------------------------------------------------------------------
Michael Watzek Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------
Re: JIRA JDO-68
Posted by Andy Jefferson <an...@jpox.org>.
> I changed the column types of table "FIELDSOFCHARACTER" back to INTEGER.
> I also changed the ORM metadata for class "FieldsOfCharacter", e.g.
> I'm using JPOX nightly build 2005-08-01. Can you please check and verify
> if JPOX calls "PrepraredStatement.setString" for the case above?
Hi Michael,
It's not in SVN. When it's in SVN then I'll have a look.
For the record on the issue of CHAR(1) or INTEGER, I'm not too fussed whether
we have CHAR(1), or INTEGER or whatever - all I want is consistent metadata
and schema so it's a fair test.
--
Andy
Re: JIRA JDO-68
Posted by Michelle Caisse <Mi...@Sun.COM>.
Okay, agreed. -- Michelle
Michael Watzek wrote:
> Hi Michelle,
>
> please have a look at test "TestFieldsOfCharacter". It uses
> "java.lang.Charcater.MAX_VALUE" and "java.lang.Character.MIN_VALUE".
>
> Concerning test "TestFieldsOfPrimitivechar" I am wrong. This test
> initializes character fields using real characters like 'a'. For this
> reason, I agree to change the column types to "CHAR(1)" for table
> "FIELDSOFPRIMITIVECHAR".
>
> Regards,
> Michael
>
>> Michael,
>>
>> Where are the numerical value initializations that you speak of for
>> FieldsOfCharacter and FieldsOfPrimitivechar? I don't see it.
>>
>> -- Michelle
>>
>> Michael Watzek wrote:
>>
>>> Hi Michelle, Andy,
>>>
>>> sorry I did not reply earlier.
>>>
>>> I talked to Craig about this issue yesterday. We agreed on leaving
>>> tables "FIELDSOFCHARACTER", "FIELDSOFPRIMITIVECHAR", and
>>> "PCPointSingleFieldChar" as they are keeping the INTEGER columns.
>>>
>>> The rationale is that pc class instances mapped to those tables have
>>> character values which are initialized based on numerical values
>>> rather than character values, e.g. "Character.MAX_VALUE",
>>> "Character.MIN_VALUE", or
>>> "System.currentTimeMillis()%Character.MAX_VALUE".
>>>
>>> For this reason, we decided to adapt the ORM metadata rather than to
>>> adapt the schema: <field> elements corresponding to fields of type
>>> "char" or "java.lang.Character" will have "jdbc-type" attributes, e.g.
>>>
>>> <class name="PCPointSingleFieldPrimitivechar"
>>> table="PCPointSingleFieldChar">
>>> <field name="id" primary-key="true">
>>> <column name="ID" jdbc-type="INTEGER"/>
>>> </field>
>>> ...
>>> </class>
>>>
>>> For pc classes like "HashtableStringValueCollections" (etc.) the
>>> story is slightly different:
>>>
>>> They have several fields of type "java.util.Map" where (sometimes)
>>> keys are FCOs (e.g. SimpleClass instances) and values are strings.
>>> The types of keys and values differ and can be derived by the
>>> classname.
>>>
>>> Each of these fields is mapped to a separate (join) table having
>>> join columns, key columns, value columns, and index columns. In the
>>> current schema, all of these columns have type "INTEGER".
>>>
>>> This is a bug: Keys and values of type "java.lang.String" must be
>>> mapped to columns of type "VARCHAR". Furthermore, join tables which
>>> are mapped by fields of maps or sets do not have index columns.
>>> Question: Do we have to distinguish bewteen sorted maps/sets vs.
>>> non-sorted maps/sets?
>>>
>>> I'll prepare two patches today fixing these issues - one for each
>>> identity type.
>>>
>>> Regards,
>>> Michael
>>>
>>>> Hi Andy,
>>>>
>>>> This is really good, a big improvement in the error count.
>>>>
>>>> Andy Jefferson wrote:
>>>>
>>>>> ...
>>>>> Schema where column is INTEGER but should be CHAR(1)
>>>>> FieldsOfCharacter : table FIELDSOFCHARACTER has INTEGER columns
>>>>> FieldsOfPrimitivechar : table FIELDSOFPRIMITIVECHAR has INTEGER
>>>>> columns
>>>>>
>>>>>
>>>> I am fixing these.
>>>>
>>>>> Schema where column is INTEGER but should be VARCHAR(...)
>>>>> HashMapStringKeyCollections, HashMapStringValueCollections,
>>>>> MapStringKeyCollections, MapStringValueCollections,
>>>>> TreeMapStringKeyCollections, TreeMapStringValueCollections : join
>>>>> tables have the key as INTEGER instead of VARCHAR
>>>>>
>>>>>
>>>> I agree that the KEYVAL columns in *StringKeyCollections and the
>>>> VALUEVAL columns of *StringValueCollections should be VARCHAR. We
>>>> have some other fixes we need to make to the mapping for these, so
>>>> I'll make these changes with those.
>>>>
>>>>> Also, this change may affect other JIRA issues, but sadly
>>>>> "http://issues.apache.org" is about as unresponsive a server as
>>>>> I've ever come across, so we'll have to leave that for others to
>>>>> work out ;-)
>>>>>
>>>>>
>>>>>
>>>> The server seems to have come to life again. I will update the
>>>> issues soon.
>>>>
>>>> -- Michelle
>>>
>>>
>>>
>>>
>>>
>
>
Re: JIRA JDO-68
Posted by Michael Watzek <mw...@spree.de>.
Hi Michelle,
please have a look at test "TestFieldsOfCharacter". It uses
"java.lang.Charcater.MAX_VALUE" and "java.lang.Character.MIN_VALUE".
Concerning test "TestFieldsOfPrimitivechar" I am wrong. This test
initializes character fields using real characters like 'a'. For this
reason, I agree to change the column types to "CHAR(1)" for table
"FIELDSOFPRIMITIVECHAR".
Regards,
Michael
> Michael,
>
> Where are the numerical value initializations that you speak of for
> FieldsOfCharacter and FieldsOfPrimitivechar? I don't see it.
>
> -- Michelle
>
> Michael Watzek wrote:
>
>> Hi Michelle, Andy,
>>
>> sorry I did not reply earlier.
>>
>> I talked to Craig about this issue yesterday. We agreed on leaving
>> tables "FIELDSOFCHARACTER", "FIELDSOFPRIMITIVECHAR", and
>> "PCPointSingleFieldChar" as they are keeping the INTEGER columns.
>>
>> The rationale is that pc class instances mapped to those tables have
>> character values which are initialized based on numerical values
>> rather than character values, e.g. "Character.MAX_VALUE",
>> "Character.MIN_VALUE", or
>> "System.currentTimeMillis()%Character.MAX_VALUE".
>>
>> For this reason, we decided to adapt the ORM metadata rather than to
>> adapt the schema: <field> elements corresponding to fields of type
>> "char" or "java.lang.Character" will have "jdbc-type" attributes, e.g.
>>
>> <class name="PCPointSingleFieldPrimitivechar"
>> table="PCPointSingleFieldChar">
>> <field name="id" primary-key="true">
>> <column name="ID" jdbc-type="INTEGER"/>
>> </field>
>> ...
>> </class>
>>
>> For pc classes like "HashtableStringValueCollections" (etc.) the story
>> is slightly different:
>>
>> They have several fields of type "java.util.Map" where (sometimes)
>> keys are FCOs (e.g. SimpleClass instances) and values are strings. The
>> types of keys and values differ and can be derived by the classname.
>>
>> Each of these fields is mapped to a separate (join) table having join
>> columns, key columns, value columns, and index columns. In the current
>> schema, all of these columns have type "INTEGER".
>>
>> This is a bug: Keys and values of type "java.lang.String" must be
>> mapped to columns of type "VARCHAR". Furthermore, join tables which
>> are mapped by fields of maps or sets do not have index columns.
>> Question: Do we have to distinguish bewteen sorted maps/sets vs.
>> non-sorted maps/sets?
>>
>> I'll prepare two patches today fixing these issues - one for each
>> identity type.
>>
>> Regards,
>> Michael
>>
>>> Hi Andy,
>>>
>>> This is really good, a big improvement in the error count.
>>>
>>> Andy Jefferson wrote:
>>>
>>>> ...
>>>> Schema where column is INTEGER but should be CHAR(1)
>>>> FieldsOfCharacter : table FIELDSOFCHARACTER has INTEGER columns
>>>> FieldsOfPrimitivechar : table FIELDSOFPRIMITIVECHAR has INTEGER columns
>>>>
>>>>
>>> I am fixing these.
>>>
>>>> Schema where column is INTEGER but should be VARCHAR(...)
>>>> HashMapStringKeyCollections, HashMapStringValueCollections,
>>>> MapStringKeyCollections, MapStringValueCollections,
>>>> TreeMapStringKeyCollections, TreeMapStringValueCollections : join
>>>> tables have the key as INTEGER instead of VARCHAR
>>>>
>>>>
>>> I agree that the KEYVAL columns in *StringKeyCollections and the
>>> VALUEVAL columns of *StringValueCollections should be VARCHAR. We
>>> have some other fixes we need to make to the mapping for these, so
>>> I'll make these changes with those.
>>>
>>>> Also, this change may affect other JIRA issues, but sadly
>>>> "http://issues.apache.org" is about as unresponsive a server as I've
>>>> ever come across, so we'll have to leave that for others to work out
>>>> ;-)
>>>>
>>>>
>>>>
>>> The server seems to have come to life again. I will update the
>>> issues soon.
>>>
>>> -- Michelle
>>
>>
>>
>>
--
-------------------------------------------------------------------
Michael Watzek Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------
Re: JIRA JDO-68
Posted by Michelle Caisse <Mi...@Sun.COM>.
Michael,
Where are the numerical value initializations that you speak of for
FieldsOfCharacter and FieldsOfPrimitivechar? I don't see it.
-- Michelle
Michael Watzek wrote:
> Hi Michelle, Andy,
>
> sorry I did not reply earlier.
>
> I talked to Craig about this issue yesterday. We agreed on leaving
> tables "FIELDSOFCHARACTER", "FIELDSOFPRIMITIVECHAR", and
> "PCPointSingleFieldChar" as they are keeping the INTEGER columns.
>
> The rationale is that pc class instances mapped to those tables have
> character values which are initialized based on numerical values
> rather than character values, e.g. "Character.MAX_VALUE",
> "Character.MIN_VALUE", or
> "System.currentTimeMillis()%Character.MAX_VALUE".
>
> For this reason, we decided to adapt the ORM metadata rather than to
> adapt the schema: <field> elements corresponding to fields of type
> "char" or "java.lang.Character" will have "jdbc-type" attributes, e.g.
>
> <class name="PCPointSingleFieldPrimitivechar"
> table="PCPointSingleFieldChar">
> <field name="id" primary-key="true">
> <column name="ID" jdbc-type="INTEGER"/>
> </field>
> ...
> </class>
>
> For pc classes like "HashtableStringValueCollections" (etc.) the story
> is slightly different:
>
> They have several fields of type "java.util.Map" where (sometimes)
> keys are FCOs (e.g. SimpleClass instances) and values are strings. The
> types of keys and values differ and can be derived by the classname.
>
> Each of these fields is mapped to a separate (join) table having join
> columns, key columns, value columns, and index columns. In the current
> schema, all of these columns have type "INTEGER".
>
> This is a bug: Keys and values of type "java.lang.String" must be
> mapped to columns of type "VARCHAR". Furthermore, join tables which
> are mapped by fields of maps or sets do not have index columns.
> Question: Do we have to distinguish bewteen sorted maps/sets vs.
> non-sorted maps/sets?
>
> I'll prepare two patches today fixing these issues - one for each
> identity type.
>
> Regards,
> Michael
>
>> Hi Andy,
>>
>> This is really good, a big improvement in the error count.
>>
>> Andy Jefferson wrote:
>>
>>> ...
>>> Schema where column is INTEGER but should be CHAR(1)
>>> FieldsOfCharacter : table FIELDSOFCHARACTER has INTEGER columns
>>> FieldsOfPrimitivechar : table FIELDSOFPRIMITIVECHAR has INTEGER columns
>>>
>>>
>> I am fixing these.
>>
>>> Schema where column is INTEGER but should be VARCHAR(...)
>>> HashMapStringKeyCollections, HashMapStringValueCollections,
>>> MapStringKeyCollections, MapStringValueCollections,
>>> TreeMapStringKeyCollections, TreeMapStringValueCollections : join
>>> tables have the key as INTEGER instead of VARCHAR
>>>
>>>
>> I agree that the KEYVAL columns in *StringKeyCollections and the
>> VALUEVAL columns of *StringValueCollections should be VARCHAR. We
>> have some other fixes we need to make to the mapping for these, so
>> I'll make these changes with those.
>>
>>> Also, this change may affect other JIRA issues, but sadly
>>> "http://issues.apache.org" is about as unresponsive a server as I've
>>> ever come across, so we'll have to leave that for others to work out
>>> ;-)
>>>
>>>
>>>
>> The server seems to have come to life again. I will update the
>> issues soon.
>>
>> -- Michelle
>
>
>
Re: JIRA JDO-68
Posted by Michael Watzek <mw...@spree.de>.
Hi Andy,
I changed the column types of table "FIELDSOFCHARACTER" back to INTEGER.
I also changed the ORM metadata for class "FieldsOfCharacter", e.g.
<class name="FieldsOfPrimitivechar" table="FIELDSOFPRIMITIVECHAR">
...
<field name="char0">
<column name="CHAR0" jdbc-type="INTEGER"/>
</field>
...
</class>
Running test "TestFieldsOfCharacter" I receive an exception at
pm.makePeristent (see below). Looking at the stacktrace it seems that
JPOX calls PreparedStatement.setString though I specified "INTEGER" above.
The bound value is "java.lang.Character.MIN_VALUE". The same happens for
"java.lang.Character.MAX_VALUE". I do not receive an exception when I
bind a char value like '1' and '2'.
I'm using JPOX nightly build 2005-08-01. Can you please check and verify
if JPOX calls "PrepraredStatement.setString" for the case above?
Regards,
MIchael
[java] ERROR 22018: Invalid character string format for type INTEGER.
[java] at
org.apache.derby.iapi.error.StandardException.newException(StandardException.java)
[java] at
org.apache.derby.iapi.types.DataType.invalidFormat(DataType.java)
[java] at
org.apache.derby.iapi.types.SQLInteger.setValue(SQLInteger.java)
[java] at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.setString(EmbedPreparedStatement.java)
[java] at
org.jpox.store.rdbms.mapping.CharRDBMSMapping.setObject(CharRDBMSMapping.java:531)
[java] at
org.jpox.store.mapping.SingleFieldMapping.setObject(SingleFieldMapping.java:235)
[java] at
org.jpox.store.rdbms.fieldmanager.ParameterSetter.storeObjectField(ParameterSetter.java:129)
[java] at
org.jpox.state.StateManagerImpl.providedObjectField(StateManagerImpl.java:2402)
[java] at
org.apache.jdo.tck.pc.fieldtypes.FieldsOfCharacter.jdoProvideField(FieldsOfCharacter.java)
[java] at
org.apache.jdo.tck.pc.fieldtypes.FieldsOfCharacter.jdoProvideFields(FieldsOfCharacter.java)
[java] at
org.jpox.state.StateManagerImpl.provideFields(StateManagerImpl.java:2740)
[java] at
org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:241)
[java] at
org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:1750)
[java] at
org.jpox.store.StoreManager.insert(StoreManager.java:721)
[java] at
org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3092)
[java] at
org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3065)
[java] at
org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1014)
[java] at
org.jpox.AbstractPersistenceManager.makePersistent(AbstractPersistenceManager.java:1050)
[java] at
org.apache.jdo.tck.models.fieldtypes.TestFieldsOfCharacter.runTest(TestFieldsOfCharacter.java:90)
[java] at
org.apache.jdo.tck.models.fieldtypes.TestFieldsOfCharacter.test(TestFieldsOfCharacter.java:66)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[java] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:197)
[java] at
org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:128)
[java] at
org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:106)
> Hi Michelle, Andy,
>
> sorry I did not reply earlier.
>
> I talked to Craig about this issue yesterday. We agreed on leaving
> tables "FIELDSOFCHARACTER", "FIELDSOFPRIMITIVECHAR", and
> "PCPointSingleFieldChar" as they are keeping the INTEGER columns.
>
> The rationale is that pc class instances mapped to those tables have
> character values which are initialized based on numerical values rather
> than character values, e.g. "Character.MAX_VALUE",
> "Character.MIN_VALUE", or "System.currentTimeMillis()%Character.MAX_VALUE".
>
> For this reason, we decided to adapt the ORM metadata rather than to
> adapt the schema: <field> elements corresponding to fields of type
> "char" or "java.lang.Character" will have "jdbc-type" attributes, e.g.
>
> <class name="PCPointSingleFieldPrimitivechar"
> table="PCPointSingleFieldChar">
> <field name="id" primary-key="true">
> <column name="ID" jdbc-type="INTEGER"/>
> </field>
> ...
> </class>
>
> For pc classes like "HashtableStringValueCollections" (etc.) the story
> is slightly different:
>
> They have several fields of type "java.util.Map" where (sometimes) keys
> are FCOs (e.g. SimpleClass instances) and values are strings. The types
> of keys and values differ and can be derived by the classname.
>
> Each of these fields is mapped to a separate (join) table having join
> columns, key columns, value columns, and index columns. In the current
> schema, all of these columns have type "INTEGER".
>
> This is a bug: Keys and values of type "java.lang.String" must be mapped
> to columns of type "VARCHAR". Furthermore, join tables which are mapped
> by fields of maps or sets do not have index columns. Question: Do we
> have to distinguish bewteen sorted maps/sets vs. non-sorted maps/sets?
>
> I'll prepare two patches today fixing these issues - one for each
> identity type.
>
> Regards,
> Michael
>
>> Hi Andy,
>>
>> This is really good, a big improvement in the error count.
>>
>> Andy Jefferson wrote:
>>
>>> ...
>>> Schema where column is INTEGER but should be CHAR(1)
>>> FieldsOfCharacter : table FIELDSOFCHARACTER has INTEGER columns
>>> FieldsOfPrimitivechar : table FIELDSOFPRIMITIVECHAR has INTEGER columns
>>>
>>>
>> I am fixing these.
>>
>>> Schema where column is INTEGER but should be VARCHAR(...)
>>> HashMapStringKeyCollections, HashMapStringValueCollections,
>>> MapStringKeyCollections, MapStringValueCollections,
>>> TreeMapStringKeyCollections, TreeMapStringValueCollections : join
>>> tables have the key as INTEGER instead of VARCHAR
>>>
>>>
>> I agree that the KEYVAL columns in *StringKeyCollections and the
>> VALUEVAL columns of *StringValueCollections should be VARCHAR. We
>> have some other fixes we need to make to the mapping for these, so
>> I'll make these changes with those.
>>
>>> Also, this change may affect other JIRA issues, but sadly
>>> "http://issues.apache.org" is about as unresponsive a server as I've
>>> ever come across, so we'll have to leave that for others to work out ;-)
>>>
>>>
>>>
>> The server seems to have come to life again. I will update the issues
>> soon.
>>
>> -- Michelle
>
>
>
--
-------------------------------------------------------------------
Michael Watzek Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------
Re: JIRA JDO-68
Posted by Michael Watzek <mw...@spree.de>.
Hi Michelle, Andy,
sorry I did not reply earlier.
I talked to Craig about this issue yesterday. We agreed on leaving
tables "FIELDSOFCHARACTER", "FIELDSOFPRIMITIVECHAR", and
"PCPointSingleFieldChar" as they are keeping the INTEGER columns.
The rationale is that pc class instances mapped to those tables have
character values which are initialized based on numerical values rather
than character values, e.g. "Character.MAX_VALUE",
"Character.MIN_VALUE", or "System.currentTimeMillis()%Character.MAX_VALUE".
For this reason, we decided to adapt the ORM metadata rather than to
adapt the schema: <field> elements corresponding to fields of type
"char" or "java.lang.Character" will have "jdbc-type" attributes, e.g.
<class name="PCPointSingleFieldPrimitivechar"
table="PCPointSingleFieldChar">
<field name="id" primary-key="true">
<column name="ID" jdbc-type="INTEGER"/>
</field>
...
</class>
For pc classes like "HashtableStringValueCollections" (etc.) the story
is slightly different:
They have several fields of type "java.util.Map" where (sometimes) keys
are FCOs (e.g. SimpleClass instances) and values are strings. The types
of keys and values differ and can be derived by the classname.
Each of these fields is mapped to a separate (join) table having join
columns, key columns, value columns, and index columns. In the current
schema, all of these columns have type "INTEGER".
This is a bug: Keys and values of type "java.lang.String" must be mapped
to columns of type "VARCHAR". Furthermore, join tables which are mapped
by fields of maps or sets do not have index columns. Question: Do we
have to distinguish bewteen sorted maps/sets vs. non-sorted maps/sets?
I'll prepare two patches today fixing these issues - one for each
identity type.
Regards,
Michael
> Hi Andy,
>
> This is really good, a big improvement in the error count.
>
> Andy Jefferson wrote:
>
>> ...
>> Schema where column is INTEGER but should be CHAR(1)
>> FieldsOfCharacter : table FIELDSOFCHARACTER has INTEGER columns
>> FieldsOfPrimitivechar : table FIELDSOFPRIMITIVECHAR has INTEGER columns
>>
>>
> I am fixing these.
>
>> Schema where column is INTEGER but should be VARCHAR(...)
>> HashMapStringKeyCollections, HashMapStringValueCollections,
>> MapStringKeyCollections, MapStringValueCollections,
>> TreeMapStringKeyCollections, TreeMapStringValueCollections : join
>> tables have the key as INTEGER instead of VARCHAR
>>
>>
> I agree that the KEYVAL columns in *StringKeyCollections and the
> VALUEVAL columns of *StringValueCollections should be VARCHAR. We have
> some other fixes we need to make to the mapping for these, so I'll make
> these changes with those.
>
>> Also, this change may affect other JIRA issues, but sadly
>> "http://issues.apache.org" is about as unresponsive a server as I've
>> ever come across, so we'll have to leave that for others to work out ;-)
>>
>>
>>
> The server seems to have come to life again. I will update the issues
> soon.
>
> -- Michelle
--
-------------------------------------------------------------------
Michael Watzek Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------
Re: JIRA JDO-68
Posted by Michelle Caisse <Mi...@Sun.COM>.
Hi Andy,
This is really good, a big improvement in the error count.
Andy Jefferson wrote:
>...
>Schema where column is INTEGER but should be CHAR(1)
>FieldsOfCharacter : table FIELDSOFCHARACTER has INTEGER columns
>FieldsOfPrimitivechar : table FIELDSOFPRIMITIVECHAR has INTEGER columns
>
>
I am fixing these.
>Schema where column is INTEGER but should be VARCHAR(...)
>HashMapStringKeyCollections, HashMapStringValueCollections,
>MapStringKeyCollections, MapStringValueCollections,
>TreeMapStringKeyCollections, TreeMapStringValueCollections : join tables have
>the key as INTEGER instead of VARCHAR
>
>
I agree that the KEYVAL columns in *StringKeyCollections and the
VALUEVAL columns of *StringValueCollections should be VARCHAR. We have
some other fixes we need to make to the mapping for these, so I'll make
these changes with those.
>Also, this change may affect other JIRA issues, but sadly
>"http://issues.apache.org" is about as unresponsive a server as I've ever
>come across, so we'll have to leave that for others to work out ;-)
>
>
>
The server seems to have come to life again. I will update the issues soon.
-- Michelle