objectbridge-developers — public list for developer issues

AW: [OJB-developers] JUNIT failures & errors

[Mahler T. <tho...@it...>]

Hi,

I added this to my todo list!

cheers,=20
Thomas

> -----Urspr=FCngliche Nachricht-----
> Von: Thomas Mahler [mailto:tho...@ho...]
> Gesendet: Sonntag, 2. Juni 2002 16:22
> An: ojb
> Betreff: [OJB-developers] JUNIT failures & errors
>=20
>=20
> Hi all,
>=20
> I just checked in some minor fixes that cure most of the problems I=20
> mentioned in my last mail.
>=20
> I set some log-messages in JdbcAccess from .error(...) to =
.debug(...).
> This avoids all the internal stacktrace within the PB Junit tests.
> This does not compromise stability as throwing of exceptions=20
> is not touched.
>=20
> I found a minor issue in SqlUpdateStatement:
> in appendSetClause(...) it uses appendColname from the baseclass=20
> SqlStatement.
>=20
> This method is used to generate column names from field descriptors.
> It uses FieldDescriptor.getFullColumnName() to build a column name.
> This will include Schema and table name in a column name=20
> (i.e. a column=20
> "NAME" would be fullqualified as "MySchema.MyTable.NAME").
>=20
> This may work in most situations, but it does not work for Update=20
> statements in Hsqldb (AFAIK DB2 and InstantDB also don't=20
> support this).
>=20
> I refactored this code with the "template method" pattern,=20
> that allows=20
> subclasses to override the qualification behaviour.
>=20
> Could this fix be problematic for other databases? Or could=20
> there be any=20
> cases where full-qualified names are needed within Update Statements?
>=20
> Now we have the following JUnit results:
> PersistenceBroker: 0 Failures, 0 Errors, 0 Stacktraces
> SODA: 0 Failures, 0 Errors, 0 Stacktraces
> ODMG: 0 Failures, 1 Error (resulting in some stacktracing)
>=20
> The error is in test.ojb.odmg.OneToOneTest.testSave().
>=20
> I hope to get this fixed soon.
>=20
> cheers,
>=20
> Thomas
>=20
>=20
> _______________________________________________________________
>=20
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- =
http://devcon.sprintpcs.com/adp/index.cfm
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20

Re: [OJB-developers] Migration stylesheet

[<ll...@li...>]

How about just putting the version attribute on the root element 
<descriptor-repository version="1">

Then on each change of the repository syntax (that needs migration) we 
increment the version number.

We could also just use the OJB version numbers. But they tend to change 
without the repository changes and they are doomed to get out of sync 
sooner or later.

>
>> 3)
>> For future use it would be nice if a version tag was introduced in 
>> the header. Maybe the DTDs should be named after the version. Perhaps 
>> not following the OJB versions.
>>
>

Re: [OJB-developers] JUNIT failures & errors

[Thomas M. <tho...@ho...>]

The real solution would be to test against all supported databases:

Hypersonic (HsqlDb)
MS_ACCESS
ORACLE
INSTANTDB
DB2
POSTGRESQL
MYSQL
INFORMIX
MSSQLSERVER2000

(There have also been contributions for Sybase compatibility that have 
not yet been incorporated into the distro yet. Its quite similar to 
Ms-SqlServer.)

cheers,

Thomas

Matthew baird wrote:

>   what subset of databases *should* be tested on to catch possible 
> errors? HSQLDB seems to be easy to test on, MSSQL server covers sybase 
> as well, and I know Oracle needs specific testing. Is it enough to test 
> on those three
> 
>  
> 
> 
> ------------------------------------------------------------------------
> *Do You Yahoo!?*
> Yahoo! <http://rd.yahoo.com/welcome/*http://fifaworldcup.yahoo.com> - 
> Official partner of 2002 FIFA World Cup

Re: [OJB-developers] Migration stylesheet

[Thomas M. <tho...@ho...>]

Hi Lasse,


Lasse Lindgård wrote:

>  Hi,
> 
> Here is my migration stylesheet. It has been tested against the 
> repository files of 0.8.400 and it generates output that complies with 
> the new repository dtd in 0.9
> 


Thanks for your quick solution! This will help users to migrate to the 
latest version of OJB !


> It is of beta quality only. But should be enough to get you started with 
> the migration.
> 
> Here is how to use it:
>        // Make sure that Xalan.jar is in the classpath
>        java org.apache.xalan.xslt.Process -IN *oldrepository.xml* -XSL 
> 0.8to0.9.xslt -OUT *newrepository.xml*
> 
> The stylesheet came out a bit longhanded. XSLT and the DTD is very 
> ridgid with the order of the elements and attributes, so I had to 
> implement some workarounds to get it all to add up.
>       Notes:
> 1)
> The current split into more files is not supported. You will have to do 
> that manually when you have upgraded.
> 


That's absolutely OK! Our users will be smart enough to handle this ;-)


> 2)
> Conversion strategies are out of the class-descriptors now. They are 
> just deleted by the stylesheet. I don't know if that is an error. I just 
> followed the DTD. Also most of the id attributes has been deleted. Also 
> by order of the DTD.
> 


Yes, that's right, they should just be dropped during transformation!
(We now have conversion attributes on the field-descriptor level, that 
are *not* compatible with the old class-descriptor based conversions).


> 3)
> For future use it would be nice if a version tag was introduced in the 
> header. Maybe the DTDs should be named after the version. Perhaps not 
> following the OJB versions.
> 


Good idea! Where to place this version info best?


> 4)
> Isn't all the attributes with "extent" in them spelled wrong ???
> I think it should be something like:
>    <class-descriptor class="test.ojb.broker.AB" sort="ASC" 
> isolation-level="read-uncommitted">
>        <extending-class class-ref="test.ojb.broker.A"/>
>        <extending-class class-ref="test.ojb.broker.B"/>
>    </class-descriptor>
> or <extender-class>.
> 
> If it is spelled wrong I think it should be fixed.
> 


extent is a term from the ODMG spec. The "extent of a class c" means 
"the set of all instances of class c"
It has a very similar meaning in the JDO spec.

OJB allows to define such extents across inheritance hierarchies, 
implementation hierarchies, or arbitrary sets of classes.

Thus it's not exclusively fixed to "extending" a base class.
So IMO <extent-class> or <extent-member-class> is OK.

thanks again!

Thomas


> 
> Regards
> /Lasse
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> <?xml version="1.0" ?> 
> <!--
> 	ObJectRelationalBridge - Bridging Java objects and relational dabatases
> 
> 	This stylesheets upgrades 0.8.400 repository format to 0.9 format.
> 	
> 	It is of beta quality only. But should be enough to get you started.
> 	
> 	Usage:
> 		Make sure that Xalan.jar is in the classpath
> 		java org.apache.xalan.xslt.Process -IN *oldrepository.xml* -XSL 0.8to0.9.xslt -OUT *newrepository.xml*
> 		
> 		The current split into more files is not supported. You will have to do that manually when you have upgraded.
> 
> 	Author: Lasse Lindgaard, June 2nd, 2002
> 
> -->
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
> 	<xsl:output
> 		method="xml"
> 		indent="yes"
> 		doctype-system="repository.dtd"
> 	/>
> 	
> 	<xsl:strip-space elements="*"/>
> 	
> 	<!-- default templates -->
> 	<xsl:template match="/">
> 		<xsl:apply-templates select="@*|*" mode="attribute"/>
> 		<xsl:apply-templates select="@*|node()" mode="elements"/>
> 	</xsl:template>
> 
> 	<!--
> 		make an error for unmatched nodes
> 		that will provide a simple way of change detection
> 		and provide feedback on when to write the next
> 		migration stylesheet
> 	-->
> 	<xsl:template match="@*|node()">
> 		<xsl:message terminate="yes">Sorry, <xsl:copy><xsl:value-of select="local-name()"/></xsl:copy> with content <xsl:value-of select="."/> was not matched. Something went wrong. Migration failed.</xsl:message>
> 	</xsl:template>
> 	
> 	<xsl:template match="@*|node()" mode="attribute"></xsl:template>
> 	
> 	<xsl:template match="@*|node()" mode="elements"></xsl:template>
> 	
> 	<xsl:template match="text()" priority="1" mode="attribute"></xsl:template>
> 	
> 	<xsl:template match="text()" priority="1" mode="elements"><xsl:copy/></xsl:template>
> 	
> 	<xsl:template match="comment()" priority="1" mode="attribute"><xsl:copy/></xsl:template>
> 	
> 	<xsl:template match="comment()" priority="1" mode="elements"><xsl:copy/></xsl:template>
> 	
> 	<!-- copy all ID attributes to lowercase id -->	
> 	<xsl:template match="@ID" mode="attribute">
> 		<xsl:attribute name="id"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 
> 	<xsl:template match="@id" mode="attribute">
> 		<xsl:attribute name="id"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 
> 	<!-- begin MappingRepository to descriptor-repository -->
> 	<xsl:template match="MappingRepository" mode="elements">
> 		<descriptor-repository>
> 			<xsl:apply-templates select="@*|*" mode="attribute"/>
> 			<xsl:apply-templates select="@*|node()" mode="elements"/>
> 		</descriptor-repository>
> 	</xsl:template>
> 	<!-- end MappingRepository to descriptor-repository -->
> 
> 	<!-- begin JdbcConnectionDescriptor to jdbc-connection-descriptor -->
> 	<xsl:template match="JdbcConnectionDescriptor" mode="elements">
> 		<jdbc-connection-descriptor>
> 			<xsl:apply-templates select="@*|*" mode="attribute"/>
> 		</jdbc-connection-descriptor>
> 	</xsl:template>
> 
> 	<!-- no id here -->
> 	<xsl:template match="JdbcConnectionDescriptor/@id" mode="attribute"></xsl:template>
> 
> 	<xsl:template match="dbms.name" mode="attribute">
> 		<xsl:attribute name="platform"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 	
> 	<xsl:template match="jdbc.level" mode="attribute">
> 		<xsl:attribute name="jdbc-level"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 
> 	<xsl:template match="driver.name" mode="attribute">
> 		<xsl:attribute name="driver"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 	
> 	<xsl:template match="url.protocol" mode="attribute">
> 		<xsl:attribute name="protocol"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 	
> 	<xsl:template match="url.subprotocol" mode="attribute">
> 		<xsl:attribute name="subprotocol"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 	
> 	<xsl:template match="url.dbalias" mode="attribute">
> 		<xsl:attribute name="dbalias"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 	
> 	<xsl:template match="datasource.name" mode="attribute">
> 		<xsl:attribute name="jndi-datasource-name"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 	
> 	<xsl:template match="user.name" mode="attribute">
> 		<xsl:attribute name="username"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 
> 	<xsl:template match="user.passwd" mode="attribute">
> 		<xsl:attribute name="password"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 	<!-- end JdbcConnectionDescriptor to jdbc-connection-descriptor -->
> 
> 	<!-- begin ClassDescriptor to class-descriptor -->
> 	<xsl:template match="ClassDescriptor" mode="elements">
> 		<class-descriptor>
> 			<xsl:apply-templates select="@*|*" mode="attribute"/>
> 			<xsl:apply-templates select="JdbcConnectionDescriptor" mode="elements"/>
> 			<xsl:apply-templates select="ExtentDescriptor" mode="elements"/>
> 			<xsl:apply-templates select="FieldDescriptor" mode="elements"/>
> 			<xsl:apply-templates select="ReferenceDescriptor" mode="elements"/>
> 			<xsl:apply-templates select="CollectionDescriptor" mode="elements"/>
> 		</class-descriptor>
> 	</xsl:template>
> 
> 	<!-- no id here -->
> 	<xsl:template match="ClassDescriptor/@id" mode="attribute"></xsl:template>
> 	<!-- no conversionStrategy on ClassDescriptors -->
> 	<xsl:template match="ClassDescriptor/conversionStrategy" mode="attribute"></xsl:template>
> <!-- 
> 	<xsl:template match="conversionStrategy" mode="attribute">
> 		<xsl:attribute name="conversion"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
>  -->
> 	<xsl:template match="class.name" mode="attribute">
> 		<xsl:attribute name="class"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 
> 	<xsl:template match="ExtentDescriptor/class.name" mode="attribute">
> 		<xsl:attribute name="class"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 
> 	<xsl:template match="class.proxy" mode="attribute">
> 		<xsl:attribute name="proxy"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 
> 	<xsl:template match="schema.name" mode="attribute">
> 		<xsl:attribute name="schema"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 
> 	<xsl:template match="table.name" mode="attribute">
> 		<xsl:attribute name="table"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 
> 	<xsl:template match="orderby" mode="attribute">
> 		<xsl:attribute name="orderby"><xsl:value-of select="."/></xsl:attribute>
> 		<xsl:apply-templates select="@*|node()" mode="attribute"/>
> 	</xsl:template>
> 
> 	<xsl:template match="@sort" mode="attribute">
> 		<xsl:attribute name="sort">
> 			<xsl:choose>
> 				<xsl:when test=".='asc'">ASC</xsl:when>
> 				<xsl:when test=".='desc'">DESC</xsl:when>
> 				<xsl:when test=".='ASC'">ASC</xsl:when>
> 				<xsl:when test=".='DESC'">DESC</xsl:when>
> 				<xsl:otherwise><xsl:message terminate="yes">Illegal sorting method <xsl:value-of select="."/></xsl:message></xsl:otherwise>
> 			</xsl:choose>
> 		</xsl:attribute>
> 	</xsl:template>
> 
> 	<xsl:template match="rowReader" mode="attribute">
> 		<xsl:attribute name="row-reader"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 
> 	<xsl:template match="@isolation" mode="attribute">
> 		<xsl:attribute name="isolation-level"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 	<!-- end ClassDescriptor to class-descriptor -->
> 
> 	<!-- begin ClassDescriptor/ExtentDescriptor  -->
> 	<xsl:template match="ClassDescriptor[ExtentDescriptor]" mode="elements">
> 		<class-descriptor class="{ExtentDescriptor/class.name}">
> 			<xsl:apply-templates select="ExtentDescriptor/@*|ExtentDescriptor/node()" mode="elements"/>
> 		</class-descriptor>
> 	</xsl:template>
> 	
> 	<!-- class.name is already defined -->
> 	
> 	<xsl:template match="class.extent" mode="elements">
> 		<extent-class class-ref="{.}"/>
> 	</xsl:template>
> 	<!-- end ExtentDescriptor to extends-descriptor -->
> 
> 	<!-- begin FieldDescriptor to field-descriptor -->
> 	<xsl:template match="FieldDescriptor" mode="elements">
> 		<field-descriptor>
> 			<xsl:apply-templates select="@*|*" mode="attribute"/>
> 			<xsl:apply-templates select="@*|node()" mode="elements"/>
> 		</field-descriptor>
> 	</xsl:template>
> 	
> 	<xsl:template match="field.name" mode="attribute">
> 		<xsl:attribute name="name"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 	
> 	<!-- table.name is already defined -->
> 	
> 	<xsl:template match="column.name" mode="attribute">
> 		<xsl:attribute name="column"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 	
> 	<xsl:template match="jdbc_type" mode="attribute">
> 		<xsl:attribute name="jdbc-type"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 	
> 	<xsl:template match="PrimaryKey" mode="attribute">
> 		<xsl:attribute name="primarykey"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 	
> 	<xsl:template match="autoincrement" mode="attribute">
> 		<xsl:attribute name="autoincrement"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 	
> 	<xsl:template match="locking" mode="attribute">
> 		<xsl:attribute name="locking"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 	
> 	<!-- end FieldDescriptor to field-descriptor -->
> 
> 	<!-- begin CollectionDescriptor to collection-descriptor -->
> 	<xsl:template match="CollectionDescriptor" mode="elements">
> 		<collection-descriptor>
> 			<xsl:apply-templates select="@*|*" mode="attribute"/>
> 			<xsl:apply-templates select="@*|node()" mode="elements"/>
> 		</collection-descriptor>
> 	</xsl:template>
> 
> 	<!-- no id here -->
> 	<xsl:template match="CollectionDescriptor/@id" mode="attribute"></xsl:template>
> 	
> 	<xsl:template match="cdfield.name" mode="attribute">
> 		<xsl:attribute name="name"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 	
> 	<xsl:template match="items.class" mode="attribute">
> 		<xsl:attribute name="element-class-ref"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 	
> 	<xsl:template match="collection.class" mode="attribute">
> 		<xsl:attribute name="collection-class"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 	
> 	<xsl:template match="auto.retrieve" mode="attribute">
> 		<xsl:attribute name="auto-retrieve"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 	
> 	<xsl:template match="auto.update" mode="attribute">
> 		<xsl:attribute name="auto-update"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 	
> 	<xsl:template match="auto.delete" mode="attribute">
> 		<xsl:attribute name="auto-delete"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 
> 	<xsl:template match="proxyCollection" mode="attribute">
> 		<xsl:attribute name="proxy"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 
> 	<xsl:template match="refreshCollection" mode="attribute">
> 		<xsl:attribute name="refresh"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 
> 	<xsl:template match="indirection_table" mode="attribute">
> 		<xsl:attribute name="indirection-table"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 	
> 	<!-- orderby and sort is defined earlier in the stylesheet so no need to repeat them here -->
> 	
> 	<xsl:template match="fks_pointing_to_this_class" mode="elements">
> 		<fk-pointing-to-this-class column="{.}"/>
> 	</xsl:template>
> 
> 	<xsl:template match="fks_pointing_to_items_class" mode="elements">
> 		<fk-pointing-to-element-class column="{.}"/>
> 	</xsl:template>
> 
> 	<xsl:template match="inverse_fk_descriptor_ids" mode="elements">
> 		<inverse-foreignkey field-id-ref="{.}"/>
> 	</xsl:template>
> 	<!-- end CollectionDescriptor to collection-descriptor -->
> 
> 	<!-- begin ReferenceDescriptor to reference-descriptor -->
> 	<xsl:template match="ReferenceDescriptor" mode="elements">
> 		<reference-descriptor>
> 			<xsl:apply-templates select="@*|*" mode="attribute"/>
> 			<xsl:apply-templates select="@*|node()" mode="elements"/>
> 		</reference-descriptor>
> 	</xsl:template>
> 
> 	<!-- no id here -->
> 	<xsl:template match="ReferenceDescriptor/@id" mode="attribute"></xsl:template>
> 
> 	<xsl:template match="rdfield.name" mode="attribute">
> 		<xsl:attribute name="name"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 
> 	<xsl:template match="referenced.class" mode="attribute">
> 		<xsl:attribute name="class-ref"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 
> 	<xsl:template match="refreshReference" mode="attribute">
> 		<xsl:attribute name="refresh"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 
> 	<xsl:template match="proxyReference" mode="attribute">
> 		<xsl:attribute name="proxy"><xsl:value-of select="."/></xsl:attribute>
> 	</xsl:template>
> 
> 	<xsl:template match="fk_descriptor_ids" mode="elements">
> 		<foreignkey field-id-ref="{.}"/>
> 	</xsl:template>
> 	<!-- end ReferenceDescription to reference-descriptor -->
> </xsl:stylesheet>
> 

Re: [OJB-developers] JUNIT failures & errors

[Thomas M. <tho...@ho...>]

Hi Jakob,

Jakob Braeuchi wrote:

> hi thomas,
> 
> 
>>This may work in most situations, but it does not work for Update
>>statements in Hsqldb (AFAIK DB2 and InstantDB also don't support this).
>>
> 
> this is one of the main problems when dealing with multiple databases, i use
> mysql as test database and there it works.


I agree!


> for some tests i also use ms-access but i never worked with hsqldb.
> we need some kind of test platform, where we can run accesslayer-code
> against _all_ supported databases.
> 


Yes, that would be the best solution.
But at my company I only have access to DB2, Oracle, MS-Access, and 
Hypersonic.

Licencing RDBMS is expensive ! It's also a know-how problem. I don't 
feel like learning about admistrating say Informix.

Maybe we can set up a kind of "distributed test farm" ?
Maybe it would be easier to just share the reponsibilities for testing 
against special platforms,
say:
Jakob : MySql
Thomas: HsqlDb, DB2
...
...

cheers,

thomas


> jakob
> 
> ----- Original Message -----
> From: "Thomas Mahler" <tho...@ho...>
> To: "ojb" <obj...@li...>
> Sent: Sunday, June 02, 2002 4:22 PM
> Subject: [OJB-developers] JUNIT failures & errors
> 
> 
> 
>>Hi all,
>>
>>I just checked in some minor fixes that cure most of the problems I
>>mentioned in my last mail.
>>
>>I set some log-messages in JdbcAccess from .error(...) to .debug(...).
>>This avoids all the internal stacktrace within the PB Junit tests.
>>This does not compromise stability as throwing of exceptions is not
>>
> touched.
> 
>>I found a minor issue in SqlUpdateStatement:
>>in appendSetClause(...) it uses appendColname from the baseclass
>>SqlStatement.
>>
>>This method is used to generate column names from field descriptors.
>>It uses FieldDescriptor.getFullColumnName() to build a column name.
>>This will include Schema and table name in a column name (i.e. a column
>>"NAME" would be fullqualified as "MySchema.MyTable.NAME").
>>
>>This may work in most situations, but it does not work for Update
>>statements in Hsqldb (AFAIK DB2 and InstantDB also don't support this).
>>
>>I refactored this code with the "template method" pattern, that allows
>>subclasses to override the qualification behaviour.
>>
>>Could this fix be problematic for other databases? Or could there be any
>>cases where full-qualified names are needed within Update Statements?
>>
>>Now we have the following JUnit results:
>>PersistenceBroker: 0 Failures, 0 Errors, 0 Stacktraces
>>SODA: 0 Failures, 0 Errors, 0 Stacktraces
>>ODMG: 0 Failures, 1 Error (resulting in some stacktracing)
>>
>>The error is in test.ojb.odmg.OneToOneTest.testSave().
>>
>>I hope to get this fixed soon.
>>
>>cheers,
>>
>>Thomas
>>
>>
>>_______________________________________________________________
>>
>>Don't miss the 2002 Sprint PCS Application Developer's Conference
>>August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>>
>>_______________________________________________
>>Objectbridge-developers mailing list
>>Obj...@li...
>>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>>
>>
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 
> 
> 
> 

Re: [OJB-developers] JUNIT failures & errors

[Jakob B. <jbr...@ho...>]

hi

what about mysql and msaccess, db2 ?
i think msaccess is on the list of supported databases, mysql is =
mentioned to run with little or no problem.
i agree about hsqldb, i've already set up the test-database and =
successfully ran all tests against it.=20
and i promise to use hsqldb as a test platform in the future...

jakob
  ----- Original Message -----=20
  From: Matthew baird=20
  To: Jakob Braeuchi ; Thomas Mahler ; ojb=20
  Sent: Sunday, June 02, 2002 9:15 PM
  Subject: Re: [OJB-developers] JUNIT failures & errors


  what subset of databases *should* be tested on to catch possible =
errors? HSQLDB seems to be easy to test on, MSSQL server covers sybase =
as well, and I know Oracle needs specific testing. Is it enough to test =
on those three=20

  =20





-------------------------------------------------------------------------=
-----
  Do You Yahoo!?
  Yahoo! - Official partner of 2002 FIFA World Cup

Re: [OJB-developers] JUNIT failures & errors

[Matthew b. <mat...@ya...>]

 what subset of databases *should* be tested on to catch possible errors? HSQLDB seems to be easy to test on, MSSQL server covers sybase as well, and I know Oracle needs specific testing. Is it enough to test on those three
  



---------------------------------
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup

Re: [OJB-developers] JUNIT failures & errors

[Jakob B. <jbr...@ho...>]

hi thomas,

> This may work in most situations, but it does not work for Update
> statements in Hsqldb (AFAIK DB2 and InstantDB also don't support this).

this is one of the main problems when dealing with multiple databases, i use
mysql as test database and there it works.
for some tests i also use ms-access but i never worked with hsqldb.
we need some kind of test platform, where we can run accesslayer-code
against _all_ supported databases.

jakob

----- Original Message -----
From: "Thomas Mahler" <tho...@ho...>
To: "ojb" <obj...@li...>
Sent: Sunday, June 02, 2002 4:22 PM
Subject: [OJB-developers] JUNIT failures & errors


> Hi all,
>
> I just checked in some minor fixes that cure most of the problems I
> mentioned in my last mail.
>
> I set some log-messages in JdbcAccess from .error(...) to .debug(...).
> This avoids all the internal stacktrace within the PB Junit tests.
> This does not compromise stability as throwing of exceptions is not
touched.
>
> I found a minor issue in SqlUpdateStatement:
> in appendSetClause(...) it uses appendColname from the baseclass
> SqlStatement.
>
> This method is used to generate column names from field descriptors.
> It uses FieldDescriptor.getFullColumnName() to build a column name.
> This will include Schema and table name in a column name (i.e. a column
> "NAME" would be fullqualified as "MySchema.MyTable.NAME").
>
> This may work in most situations, but it does not work for Update
> statements in Hsqldb (AFAIK DB2 and InstantDB also don't support this).
>
> I refactored this code with the "template method" pattern, that allows
> subclasses to override the qualification behaviour.
>
> Could this fix be problematic for other databases? Or could there be any
> cases where full-qualified names are needed within Update Statements?
>
> Now we have the following JUnit results:
> PersistenceBroker: 0 Failures, 0 Errors, 0 Stacktraces
> SODA: 0 Failures, 0 Errors, 0 Stacktraces
> ODMG: 0 Failures, 1 Error (resulting in some stacktracing)
>
> The error is in test.ojb.odmg.OneToOneTest.testSave().
>
> I hope to get this fixed soon.
>
> cheers,
>
> Thomas
>
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>

[OJB-developers] Migration stylesheet

[<ll...@li...>]

  Hi,

Here is my migration stylesheet. It has been tested against the 
repository files of 0.8.400 and it generates output that complies with 
the new repository dtd in 0.9

It is of beta quality only. But should be enough to get you started with 
the migration.

Here is how to use it:
        // Make sure that Xalan.jar is in the classpath
        java org.apache.xalan.xslt.Process -IN *oldrepository.xml* -XSL 
0.8to0.9.xslt -OUT *newrepository.xml*

The stylesheet came out a bit longhanded. XSLT and the DTD is very 
ridgid with the order of the elements and attributes, so I had to 
implement some workarounds to get it all to add up.
       
Notes:
1)
The current split into more files is not supported. You will have to do 
that manually when you have upgraded.

2)
Conversion strategies are out of the class-descriptors now. They are 
just deleted by the stylesheet. I don't know if that is an error. I just 
followed the DTD. Also most of the id attributes has been deleted. Also 
by order of the DTD.

3)
For future use it would be nice if a version tag was introduced in the 
header. Maybe the DTDs should be named after the version. Perhaps not 
following the OJB versions.

4)
Isn't all the attributes with "extent" in them spelled wrong ???
I think it should be something like:
    <class-descriptor class="test.ojb.broker.AB" sort="ASC" 
isolation-level="read-uncommitted">
        <extending-class class-ref="test.ojb.broker.A"/>
        <extending-class class-ref="test.ojb.broker.B"/>
    </class-descriptor>
or <extender-class>.

If it is spelled wrong I think it should be fixed.


Regards
/Lasse

[OJB-developers] JUNIT failures & errors

[Thomas M. <tho...@ho...>]

Hi all,

I just checked in some minor fixes that cure most of the problems I 
mentioned in my last mail.

I set some log-messages in JdbcAccess from .error(...) to .debug(...).
This avoids all the internal stacktrace within the PB Junit tests.
This does not compromise stability as throwing of exceptions is not touched.

I found a minor issue in SqlUpdateStatement:
in appendSetClause(...) it uses appendColname from the baseclass 
SqlStatement.

This method is used to generate column names from field descriptors.
It uses FieldDescriptor.getFullColumnName() to build a column name.
This will include Schema and table name in a column name (i.e. a column 
"NAME" would be fullqualified as "MySchema.MyTable.NAME").

This may work in most situations, but it does not work for Update 
statements in Hsqldb (AFAIK DB2 and InstantDB also don't support this).

I refactored this code with the "template method" pattern, that allows 
subclasses to override the qualification behaviour.

Could this fix be problematic for other databases? Or could there be any 
cases where full-qualified names are needed within Update Statements?

Now we have the following JUnit results:
PersistenceBroker: 0 Failures, 0 Errors, 0 Stacktraces
SODA: 0 Failures, 0 Errors, 0 Stacktraces
ODMG: 0 Failures, 1 Error (resulting in some stacktracing)

The error is in test.ojb.odmg.OneToOneTest.testSave().

I hope to get this fixed soon.

cheers,

Thomas

[OJB-developers] JUNIT failures and errors

[Thomas M. <tho...@ho...>]

Hi all,

This weekend I wanted to assemble a 0.9 release of OJB.

I wanted to hand over this code base to Jason for our migration to Jakarta.

Unfortunately I found *a lot* of failures and errors in our Junit tests 
that make those steps impossible!

I fact those errors are so severe that they chrash my 1.3 VM !!!
Under Jdk 1.4 the JVM stays alive, but the errors are so dramatic that 
even the tests-broker.txt is not written!

For ODMG I get 4 failures and 2 errors
For SODA I get 1 failure

I'm not amused!

We have very simple and clear rules regarding check in (see 
http://objectbridge.sf.net/team.html).

Last week we had a lot of (ugly but harmless) stacktraces and to failures
Now we have a growing number of test failures and errors, and a total 
crash of the PB tests.

I know that it is sometimes difficult to check consistency when others 
have been working on a file I want to checkin.
I know that coding is more fun then testing.

But this situation is simply not acceptable!

Please: everybody re-check the stuff you checked in in the last 2 weeks 
and help to get OJB working!



here is my timeline for June:
- release 0.9 on Monday 3rd (postponed for a week due to "quality 
problems") With this release we are feature complete for 1.0! I want to 
have 1 month time to stabilize things and to complete documentation.

- Rename package structure to org.apache.ojb, add apache license, move 
to Jakarta,

- Bugfixes, documentation

- release 1.0 end June (as 0.9 is delayed, this may also be critical)

cheers,

Thomas

Re: [OJB-developers] Database generated primary keys

[Thomas M. <tho...@ho...>]

Hi Brian,

Brian Devries wrote:

> Hi all,
> 
> I was wondering if anyone has tried to, or if there are plans to expand
> OJB to support database generated primary keys, such as Informix's
> SERIAL type.
> 


There is a code-contribution to use OJB with oracle sequencenumbers. But 
it has not been incorporated to the main distribution yet.

There have been no request in this direction so far.

Even commercial products like TopLink only support Oracle sequence numbers.


> I am running into a problem using the included SequenceManagers when the
> tables being mapped to may be inserted into by other non-OJB processes.


Right, this is currently not handled by OJB. I'm currently facing the 
same problem in a project in my company.


> In such cases OJB may begin a transaction to insert a new row, grab the
> max value from the table in question, but then by the time it actually
> does the insert, another process may have already inserted the next row.
> 
> There seem to be two options, to create a SequenceManager which gets the
> max value on the table and places a lock on the table until the
> transaction is complete, or to have OJB try to support the built in
> SERIAL-type fields of the databases.
> 


You might also implement a SequenceManager, that does not lock the 
table, but inserts a row with the new primary key.
This will preserve uniqueness of the primary key accross all running 
applications (incl. OJB).

In my above mentioned project I will go this way.


>>From looking at the architecture of the ODMG code, however, that may be
> pretty tricky. 


Right The ODMG implementation is very "far away" from RDBMS specifics.
Things like sequence-numbering etc should be handled on the 
PersistenceBroker layer.

It looks like when an object is first locked, a new key
> is generated using the SequenceManager if one is not already set and the
> autoincrement indicator is true. This allows the LockManager to lock a
> new object using the newly generated primary key. It is not until later,
> however, when the ODMG transaction is committed, that the insert is
> actually performed. This means that if you were going to try to rely on
> the database to generate the primary key on insert, that you don't have
> a primary key when the object is first locked to hold a lock on.
> 
> One question that came to mind was if a lock really needs to be placed
> on a new object that is deferring its primary key generation to the
> database? Instead, could the identity of that object just be unique to
> that instance until a primary key is assigned to it during the commit?
> This would mean that the assignment of reference foreign keys and
> collection inverse foreign keys would have to be moved from the lock
> stage to the commit stage, but I can't think of why that would be a
> problem.


The reason is not so obvious to see. here is why:

Say you have two classes A and B. A has a collection of Bs.
say we have an object a of type A that holds a collection of 5 Bs.

Navigability is unidirectional from A to B. That is a B has no reference 
to its A!

The objects are newly created and primary and foreign keys are not assigned.

Now we lock a (and the 5 Bs) to a tx without assignment of Identities 
and foreignkeys.

Now we try to commit the tx:
If we try to store one of the Bs it won't have its foreignkey attribute 
pointing to its A filled.

As there is no reference back to a the Transactionmanager has no way to 
know how to fill the foreign key attribute.

The only place the transactionmanager can do this is on registering A, 
or later when Bs are added to the collection attribute of a.

I hope this makes things clearer a bit.


cheers,

Thomas


> 
> Has anyone gone down this road before, or have thoughts on this?
> 
> -Brian
> 
> --
> Brian DeVries                   Sr. Software Engineer
> mailto:bde...@in...   http://www.intraware.com
> Voice: 925.253.6516             Fax: 925.253.6785
> --------------------------------------------------------
> Intraware... The leading provider of Electronic Software
>              Delivery and Management (ESDM) Solutions
> 
> 
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 
> 
> 
> 

Re: [OJB-developers] OJB and Jakarta

[Thomas M. <tho...@ho...>]

Hi Jason, hi all,

As I told you before I planned to assemble a new release this weekend.
Unfortunatley we have some problems with the latest sources as we have 
an increasing number of failing JUNIT tests.

We will have to get things running before I can assemble a new public 
release!

I also don't like the idea to shift a buggy code-base. I think we should 
make our homeworks first.


That's why I'd suggest to do the move later (maybe next weekend).

cheers,

Thomas


Jason van Zyl wrote:

> Hi Thomas,
> 
> Do you want to try and move the code over this weekend? I'm ready if you
> are :-)
> 
> Also I'm going to use the user names as they are listed on the developer
> page so if there is anyone that wants a different account name on the
> apache machine mail me privately with your request.
> 
> 

[OJB-developers] OJB and Jakarta

[Jason v. Z. <jv...@ze...>]

Hi Thomas,

Do you want to try and move the code over this weekend? I'm ready if you
are :-)

Also I'm going to use the user names as they are listed on the developer
page so if there is anyone that wants a different account name on the
apache machine mail me privately with your request.

-- 
jvz.

Jason van Zyl
jv...@ap...

http://tambora.zenplex.org

[OJB-developers] Database generated primary keys

[Brian D. <bde...@in...>]

Hi all,

I was wondering if anyone has tried to, or if there are plans to expand
OJB to support database generated primary keys, such as Informix's
SERIAL type.

I am running into a problem using the included SequenceManagers when the
tables being mapped to may be inserted into by other non-OJB processes.
In such cases OJB may begin a transaction to insert a new row, grab the
max value from the table in question, but then by the time it actually
does the insert, another process may have already inserted the next row.

There seem to be two options, to create a SequenceManager which gets the
max value on the table and places a lock on the table until the
transaction is complete, or to have OJB try to support the built in
SERIAL-type fields of the databases.

From looking at the architecture of the ODMG code, however, that may be
pretty tricky. It looks like when an object is first locked, a new key
is generated using the SequenceManager if one is not already set and the
autoincrement indicator is true. This allows the LockManager to lock a
new object using the newly generated primary key. It is not until later,
however, when the ODMG transaction is committed, that the insert is
actually performed. This means that if you were going to try to rely on
the database to generate the primary key on insert, that you don't have
a primary key when the object is first locked to hold a lock on.

One question that came to mind was if a lock really needs to be placed
on a new object that is deferring its primary key generation to the
database? Instead, could the identity of that object just be unique to
that instance until a primary key is assigned to it during the commit?
This would mean that the assignment of reference foreign keys and
collection inverse foreign keys would have to be moved from the lock
stage to the commit stage, but I can't think of why that would be a
problem.

Has anyone gone down this road before, or have thoughts on this?

-Brian

--
Brian DeVries                   Sr. Software Engineer
mailto:bde...@in...   http://www.intraware.com
Voice: 925.253.6516             Fax: 925.253.6785
--------------------------------------------------------
Intraware... The leading provider of Electronic Software
             Delivery and Management (ESDM) Solutions

[OJB-developers] Re: OJB with Sybase dbms

[Thomas M. <tho...@ho...>]

Hi Lorenzo,

Thanks for your contribution!
Good to hear, that you got things running now!
For the time being I will add you stuff to the contributions package. 
We'll have to incorporate this into the main codebase later.

cheers,

Thomas


Lorenzo Nicora wrote:

> Hello.
> I know I disturbed you requesting help to support Sybase 
> DBMS. Sorry, I know this was the wrong place. :*)
> 
> Anyway...
> I made it running and passing all the junit and performance 
> tests.
> 
> Here are changes needed to make it work (I already posted it 
> in the forum).
> 
> ######################################
> ###### Changes to db-setup.sql ####### 
> ######################################
> 
> ;Add definition of "SYBASE" dbms
> 
> //#ifdef SYBASE
> ; for Sybase ASA 7 and 8
> d com.sybase.jdbc2.jdbc.SybDriver;
> o jdbc:sybase:Tds:127.0.0.1:2638?
> user=DBA&password=SQL;
> 
> ; Connecting to Sybase by jdbc columns are NOT NULL by 
> default
> ; this statement is mandatory only creating tables
> e set temporary option ALLOW_NULLS_BY_DEFAULT=On;
> //#endif
> 
> ;Add IFDEFs in table column definition for SYBASE 
> ;IDENTICAL to MSSQLSERVER2000 for all table
> 
> 
> ######################################
> ##### Changes to repository.xml ###### 
> ######################################
> 
> <!-- Add support for SYBASE dbms -->
> 
> <JdbcConnectionDescriptor id="default">
>   <dbms.name>SYBASE</dbms.name>
>   <jdbc.level>2.0</jdbc.level>
>   
> <driver.name>com.sybase.jdbc2.jdbc.SybDriver</driver.name
> 
>   <url.protocol>jdbc</url.protocol>
>   <url.subprotocol>sybase:Tds</url.subprotocol>
>   <url.dbalias>127.0.0.1:2638</url.dbalias>
>   <user.name>DBA</user.name>
>   <user.passwd>SQL</user.passwd>
> </JdbcConnectionDescriptor>
> 
> ################################################
> ## ojb.broker.platforms.Platform implemention ##
> ################################################
> package ojb.broker.platforms;
> 
> import java.sql.*;
> 
> /**
>  * @version 	1.0
>  * @author 	lorenzo nicora
>  */
> public class PlatformSYBASEImpl extends 
> PlatformDefaultImpl
> {
>   /**
>    * A strange behaviour of JConnect dirver cause wrong 
> rounding fetching/reading
>    * TIMESTAMP fields on 1/1000 seconds (a bug?).
>    * Without this patch the LockedByTimestamp test always 
> fails.
>    * This method turn around the problem, rounding all 
> TIMESTAMPs written by OJB
>    * to 1/100 of second.
>    *
>    * @see Platform#setObjectForStatement
> (PreparedStatement, int, Object, int)
>    */
>   public void setObjectForStatement(PreparedStatement ps, 
> int index, Object value, int sqlType) throws 
> java.sql.SQLException
>   {
>     // Insert TIMESTAMP parameters rounding to the 1/100 
> seconds
>     if ( sqlType == Types.TIMESTAMP && value != null && 
> value instanceof Timestamp)
>     {
>       long longTime =  ((Timestamp)value).getTime() + 
> (((Timestamp)value).getNanos() / 1000000 / 10) * 10;
>       java.sql.Timestamp sqlTime = new java.sql.Timestamp
> (longTime);
>       ps.setTimestamp(index,  sqlTime);
>     }
>     else
>       super.setObjectForStatement(ps, index, value, sqlType);
>   }
> }
> ################################################
> 
> Good by
> 
>    Lorenzo
> 
> 
> 
> 
> 
> 

Re: [OJB-developers] Ojbgen code generator

[Thomas M. <tho...@ho...>]

Hi Brian,

Brian Devries wrote:

> Hi Hoang/Thomas,
> 
> A useful alternative that I have used for code generation is to use an XSLT style
> sheet to generate the interface and data object java code. Using the "Redirect"
> extension tag in Xalan, which can be used to redirect output to many different
> files, I do a transformation directly on the repository.xml into java source
> files.
> 
> Additionally, because its a simple XSLT transformation, the code generation can be
> added as a "style" task in an ant build file, so that all classes are generated
> and compiled at build time.


cool!


> 
> There's nothing else to code other than the stylesheet. I can send along mine as
> an example if you are interested.
> 


Yes, that is very interesting for us!

thanks,

Thomas


> -Brian
> 
> --
> Brian DeVries                   Sr. Software Engineer
> mailto:bde...@in...   http://www.intraware.com
> Voice: 925.253.6516             Fax: 925.253.6785
> --------------------------------------------------------
> Intraware... The leading provider of Electronic Software
>              Delivery and Management (ESDM) Solutions
> 
> 
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 
> 
> 
> 

Re: [OJB-developers] Ojbgen code generator

[Brian D. <bde...@in...>]

Hi Hoang/Thomas,

A useful alternative that I have used for code generation is to use an XSLT style
sheet to generate the interface and data object java code. Using the "Redirect"
extension tag in Xalan, which can be used to redirect output to many different
files, I do a transformation directly on the repository.xml into java source
files.

Additionally, because its a simple XSLT transformation, the code generation can be
added as a "style" task in an ant build file, so that all classes are generated
and compiled at build time.

There's nothing else to code other than the stylesheet. I can send along mine as
an example if you are interested.

-Brian

--
Brian DeVries                   Sr. Software Engineer
mailto:bde...@in...   http://www.intraware.com
Voice: 925.253.6516             Fax: 925.253.6785
--------------------------------------------------------
Intraware... The leading provider of Electronic Software
             Delivery and Management (ESDM) Solutions

Re: [OJB-developers] Question regarding extents

[Thomas M. <tho...@ho...>]

Hi again,

Matthew baird wrote:

>  I'm looking through the code trying to thoroughly grok how extents are 
> supported, and I have to admit I'm a little bit puzzled :) I was 
> wondering if someone out there could comment on my understanding of how 
> things work:
> 
> Consider having two objects mapped to the same table, but they one 
> doesn't inherit from the other. To be concrete, we have OperatingUnit 
> and EnterpriseUnit.
> 
> If I execute an OQL query "select unit from 
> com.somecompany.OperatingUnit" I would expect to get back all the 
> operatingunits and none of the enterpriseunits. To support that, I've 
> included an ojbConcreteClass mapping for each of the unit types.
> 
> OJB does it's thing and finally ends up calling the .next() on the 
> RsIterator, during which OJB will call getObjectFromResultSet which will 
> eventually call readObjectFrom
> 
> readObjectFrom then checks the ojbConcreteClass attribute, but can't 
> really use this as a discriminator since it doesn't know what you asked 
> for (for instance, the first row in the UNIT table is an enterprise 
> unit, and I asked for operatingunits) so it tries to build the 
> EnterpriseUnit using the query results of the OperatingUnit.
> 
> If EnterpriseUnit doesn't have the same fields mapped in the same order 
> as OperatingUnit, building the new instance of the object will throw an 
> exception. the exception makes its way back to the .next() routine where 
> it is caught as an Exception and rethrown as a NoSuchElementException 
> which is NOT caught in getCollectionByQuery
> 
> getCollectionByQuery is extent aware, and is ready to deal with having 
> object materialized that don't match what was asked for
> 
>  if ((itemClass.equals(candidate.getClass()))
>                     || (Proxy.isProxyClass(candidate.getClass()))
>                     || (candidate instanceof VirtualProxy))
> 
> is the important peice of code however, this code is unlikely to 
> actually be called because Object candidate = i.next(); is probably 
> going to throw a NoSuchElementException exception.
> 
> There are a couple other places where we load the object, check the type 
> and try to materialize one of those objects. Using the new row[] array 
> instead of the resultset means we have to be aware of the ordering of 
> results (we can't get them by name) which causes a problem with 2 
> objects mapped to the same table with different order of mappings. I can 
> live with that, but the materialization of an extent object with extra 
> attributes failing because row[] doesn't contain all those values is not 
> good.
> 


I agree. We'll have to improve the "mapping on one table"-stuff. (We'll 
also need support for the third possible mapping of inheritance 
hierarchies, where attributes may come from different tables.)


> If you grokked all that, here's a potential solution:
> 
> when creating the select SQL, if more than one object is mapped to the 
> table, either load the union of all the fields that *could* be used 
> dependent on object type, then store them by name in a hashmap (or come 
> up with a lighter solution to get the columns by name). Then you would 
> be guaranteed that the actual object could be created if need be. This 
> solution would allow for people to query on base class and still get 
> back base and sub classes all mapped to same table.
> 


I think this is the way to go.


> Other solution would be to somehow append the objConcreteClass 
> discriminator to the where clause, but that would not allow for loading 
> subclasses as base objects, so I don't think it's a good solution.
> 


I agree.


cheers,

Thomas


> Comments?
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> ------------------------------------------------------------------------
> *Do You Yahoo!?*
> Yahoo! <http://rd.yahoo.com/welcome/*http://fifaworldcup.yahoo.com> - 
> Official partner of 2002 FIFA World Cup

Re: [OJB-developers] Ojbgen code generator

[Thomas M. <tho...@ho...>]

Hi Hoang,

Hoang, Hai wrote:

> I've some code that read the repository.xml 


Reading a repository.xml is done by 
ojb.broker.metadata.RepositoryPersistor. I see no reason to duplicate 
this functionality. If your code uses the RepositoryPersistor, OK! If 
not please refactor it to use the RepositoryPersistor.

> and generate java code 


That's interesting. You are generating code from a 
ojb.broker.metadata.DescriptorRepository or directly from the parsed 
repository.xml file?

If you are generating from DescriptorRepository you solution could be 
the step towards the OJB code genartor stuff!

Are you using a special library for code generation, or do you generate 
Java code manually?
I'd prefer using an existing opensource library!

> for the
> following pattern from previous project (ATG) and now I want to port over to
> OJB and donate it to the ojb community.
> 



thanks!


> For example, if I have a class descriptor and these are classes will be
> generated:
> 
> User (interface)
> UserImpl (class)
> UserManager (interface)
> UserManagerImpl (class)
> 


IMO there should be some kind of template mechanism to allow 
user-defined generation schemes. Generating those for classes may be 
perfect for your environment. But others would like different schemes.
In my company we use:
User (interface)
UserBaseImpl implements User (abtract class, only getters and setters 
are implemented)
UserImpl extends UserBaseImpl (all other methods are implemented here)
UserHome (factory class)

We should not force OJB use to use a specific generation scheme.


> 1.  I would like to know, which class parses the repository.xml for
> information purposes only (without validation), so I can use the information
> in the repository to generate code.


Have a look at ojb.broker.metadata.RepositoryPersistor. This guy builds 
up the DescriptorRepository from a repository.xml (and in the near 
future from a repository.jdo) file.
BUT:it uses validation! (I don't understand why you do not to use XML 
validation???)


> 
> 2.  Can we possibly add a
> <interface.name>com.xyz.Permission</interface.name> tag to the class
> descriptor along with <class.name>com.xyz.PermissionImpl</class.name>?
> 


There is already a mechanism to define interface based extends in the 
repository. For example there is an extent declaration for 
"InterfaceArticle" in our junit testsuite repository_junit.xml declaring 
all implementations of this IF.
This could also be used to get your required information

The DescriptorRepository is meant for object/relational mapping 
information. Metainformation related to codegeneration patterns should 
be kept in a separate place.
The best way (as mentioned above) would be to provide a template 
mechanism to allow maximum flexibility.


> 3.  Can I reuse the metadata package to store the parsed information from
> the repository.xml without required runtime classes? for example, if I have
> a <class.name>com.xyz.PermissionImpl</class.name> in one of my class
> descriptor and the file is not yet genereated, will this causes me problem?
> 


Oops, you got me! This is an aspect I did not think about before! In 
fact the current DescriptorRepository relies on existing persistent 
classes. There are several places where the XmlRepositoryHandler tries a 
Class.forName(...), which will cause a lot of exceptions in the case you 
are describing. The same holds true for attribute fields (or 
getter/setter methods if you are using bean access).

But it should not be too difficult to change this.
A ClassDescriptor should be marked with a special tag saying "this class 
could not be found and should be generated".

cheers,

Thomas


> Thank you,
> 
> Hai
> 
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 
> 
> 
> 

Re: [OJB-developers] Advice on DBMS naming needed

[Thomas M. <tho...@ho...>]

+1

Oleg Nitz wrote:

> Hi,
> 
> Some time ago DBMS settings where in repository.xml and their names where in 
> mixed case: MySQL, Hsqldb, and so on. Platform class name where defined as 
> "Platform" + dbms_name + "Impl", e.g. PlatformMySQLImpl, PlatformHsqldbImpl, 
> and so on.
> Then DBMS settings have moved to profile/*.profile and for some reason their 
> names became lowercase:
>   dbmsName=mysql
>   dbmsName=hsqldb
> At some point I changed the algoritm for Platform names to 
> "Platform" + pf.substring(0, 1).toUpperCase() + pf.substring(1) + "Impl";
> so that it handled Hsqldb correctly. But now I see that this is not enough.
> I guess that the recently reported problem with MySQL may be due to this.
> I propose to return to the original DBMS names with mixed case and to 
> original Platform class name algorithm.
> Thus I am going to write 
>   dbmsName=MySQL
>   dbmsName=Hsqldb
> in profile files. 
> Any objections?
> And BTW the correct DBMS names should be listed in the documentation. 
> 
> Oleg
> 
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 
> 
> 
> 

Re: [OJB-developers] bug in sql generation

[Jakob B. <jbr...@ho...>]

hi,

i don't think we loose a lot of performance when generating the sql string.
resolving path expressions, looking for joins is imho more time consuming
and
as far as i've seen crossdb doesn't help us here.

jakob


----- Original Message -----
From: "Oleg Nitz" <on...@uk...>
To: <obj...@li...>
Sent: Thursday, May 30, 2002 11:29 PM
Subject: Re: [OJB-developers] bug in sql generation


> On Thursday 30 May 2002 23:47, tr...@th... wrote:
> > Because you are adding extra levels of complexity to OJB by trying to
> > handle all databases internally.  Abstracting this out would make it
much
> > more modular and easier to maintain and implement new databases.  Not to
> > mention better performance because crossdb uses a factory get the
> > appropriate crossdb implementation, so there's not a bunch of if(db is
> > mysql) else if(db is oracle), etc, etc.
> Travis, the same thing is done in OJB: see Platform interface,
> PlatformFactory, and so on. And database handling is completely contained
in
> ojb.broker.platforms module. The similar factory architecture is used in
> Castor. But I decided to introduce a classification of outer join syntax
of
> *all* existing RDBMS (at least all that I know). At first I thought that
> there are 3 types of syntax: SQL-92, Sybase and Oracle. Than it turned out
> that SQL-92 syntax has 2 flavours: with braces and without braces.
> And you are right, SqlStatement.java contains some number of if/else,
which
> handles these 4 types of syntax. I don't believe that this is noticable
for
> performance. But I suppose that the amount of code that handles database
> differences in OJB is less than in Castor (ojb.broker.platforms = 21K,
> org.exolab.castor.jdo.drivers = 217K), while OJB's SqlStatement.java is
much
> more powerful than Castor's QueryExpression.
>
> > And it can support everything but unions (only because unions aren't
> > supported in all dbs).  Joins are easily supported and Where statements
can
> > be infinitely nested.
> And what about aliases?
> Anyway we need to use unions with all databases that support them, thus
> CrossDB doesn't fit our needs. And supports less databases.
> Not to mention better performance of SqlStatement because it does directly
>   stringBuffer.append("X.col1");
>   stringBuffer.append("=");
>   stringBuffer.append("Y.col2");
> instead of
>   SelectQuery sq = factory.getSelectQuery();
>   ...
>   sq.addWhereCondition("X.col1", WhereCondition.EQUAL_TO, "Y.col2");
>   sq.execute();
> I guess some number of additional objects are created inside the called
> methods. And how many if/else handle constants like
WhereCondition.EQUAL_TO?
> Don't tell me that with CrossDB we will increase performance ;o)
>
> Regards,
>  Oleg
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>

RE: [OJB-developers] CVS doesn't compile

[<tr...@th...>]

That would be it.  ;-)

Up now.

Travis

---- Original Message ----
From: Oleg Nitz <on...@uk...>
Sent: 2002-05-30
To: obj...@li...
Subject: [OJB-developers] CVS doesn't compile

Probably somebody forgot to add OjbJdoXmlHandler.java to CVS...

main:
    [javac] Compiling 469 source files to /root/cvs/ojb/ojb-1-0/target/classes
    [javac] 
/root/cvs/ojb/ojb-1-0/target/src/ojb/broker/metadata/RepositoryPersistor.java:43: 
cannot resolve symbol
    [javac] symbol  : class OjbJdoXmlHandler
    [javac] location: package metadata
    [javac] import ojb.jdo.metadata.OjbJdoXmlHandler;
    [javac]                         ^
    [javac] 
/root/cvs/ojb/ojb-1-0/target/src/ojb/broker/metadata/RepositoryPersistor.java:195: 
cannot resolve symbol
    [javac] symbol  : class OjbJdoXmlHandler
    [javac] location: class ojb.broker.metadata.RepositoryPersistor
    [javac]                ContentHandler handler = new 
OjbJdoXmlHandler(repository);
    [javac]                                                 ^
    [javac] 2 errors

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Objectbridge-developers mailing list
Obj...@li...
https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

RE: Re: [OJB-developers] bug in sql generation

[<tr...@th...>]

It's your call, just bringing it to your attention.

Travis

---- Original Message ----
From: Oleg Nitz <on...@uk...>
Sent: 2002-05-30
To: obj...@li...
Subject: Re: [OJB-developers] bug in sql generation

On Thursday 30 May 2002 23:47, tr...@th... wrote:
> Because you are adding extra levels of complexity to OJB by trying to
> handle all databases internally.  Abstracting this out would make it much
> more modular and easier to maintain and implement new databases.  Not to
> mention better performance because crossdb uses a factory get the
> appropriate crossdb implementation, so there's not a bunch of if(db is
> mysql) else if(db is oracle), etc, etc.
Travis, the same thing is done in OJB: see Platform interface, 
PlatformFactory, and so on. And database handling is completely contained in 
ojb.broker.platforms module. The similar factory architecture is used in 
Castor. But I decided to introduce a classification of outer join syntax of 
*all* existing RDBMS (at least all that I know). At first I thought that 
there are 3 types of syntax: SQL-92, Sybase and Oracle. Than it turned out 
that SQL-92 syntax has 2 flavours: with braces and without braces.
And you are right, SqlStatement.java contains some number of if/else, which 
handles these 4 types of syntax. I don't believe that this is noticable for 
performance. But I suppose that the amount of code that handles database 
differences in OJB is less than in Castor (ojb.broker.platforms = 21K, 
org.exolab.castor.jdo.drivers = 217K), while OJB's SqlStatement.java is much 
more powerful than Castor's QueryExpression. 

> And it can support everything but unions (only because unions aren't
> supported in all dbs).  Joins are easily supported and Where statements can
> be infinitely nested.
And what about aliases?
Anyway we need to use unions with all databases that support them, thus 
CrossDB doesn't fit our needs. And supports less databases.
Not to mention better performance of SqlStatement because it does directly
  stringBuffer.append("X.col1");
  stringBuffer.append("=");
  stringBuffer.append("Y.col2");
instead of 
  SelectQuery sq = factory.getSelectQuery();
  ...
  sq.addWhereCondition("X.col1", WhereCondition.EQUAL_TO, "Y.col2");
  sq.execute();
I guess some number of additional objects are created inside the called 
methods. And how many if/else handle constants like WhereCondition.EQUAL_TO?
Don't tell me that with CrossDB we will increase performance ;o)

Regards,
 Oleg

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Objectbridge-developers mailing list
Obj...@li...
https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

[OJB-developers] CVS doesn't compile

[Oleg N. <on...@uk...>]

Probably somebody forgot to add OjbJdoXmlHandler.java to CVS...

main:
    [javac] Compiling 469 source files to /root/cvs/ojb/ojb-1-0/target/classes
    [javac] 
/root/cvs/ojb/ojb-1-0/target/src/ojb/broker/metadata/RepositoryPersistor.java:43: 
cannot resolve symbol
    [javac] symbol  : class OjbJdoXmlHandler
    [javac] location: package metadata
    [javac] import ojb.jdo.metadata.OjbJdoXmlHandler;
    [javac]                         ^
    [javac] 
/root/cvs/ojb/ojb-1-0/target/src/ojb/broker/metadata/RepositoryPersistor.java:195: 
cannot resolve symbol
    [javac] symbol  : class OjbJdoXmlHandler
    [javac] location: class ojb.broker.metadata.RepositoryPersistor
    [javac]                ContentHandler handler = new 
OjbJdoXmlHandler(repository);
    [javac]                                                 ^
    [javac] 2 errors