objectbridge-developers — public list for developer issues

RE: [OJB-developers] Re: Visual Tool?

[Charles A. <cha...@hp...>]

Hi All,

Sorry - I've been fairly (for which read "very") quiet on the OJB front, as
I've been having to concentrate on other important architectural issues in
our current project. 

However, at the moment we still intend to use OJB as our persistence engine,
accessed via entity beans.

> From: Thomas Mahler [mailto:tho...@ho...]
>
> Alan Mellor wrote:
> 
>  > Is the XML O/R mapping metadata entered by hand, or via a 
> visual tool?
> 
> currently it must be edited manually. But we definitely want to have
> such a tool.
> I would like to something like the TOPLink mapping workbench, which
> provides quite a lot of well structured engineering features.


Our system will be a very large one, and it is currently modelled in
Rational Rose. Rose can also generate Data Models from Object Models
(allowing the user to make important mapping decisions - it's not all
automated !), and the DDL from the Data Model (as well as java classes from
the Object Model). A couple of months ago, I investigated writing scripts
for Rose to generate the mapping file; whilst I didn't finish the script, I
did find out enough to show that it is possible.

Anyway, writing the script is on my ToDo list, and when I get round to it, I
will happily contribute it to the project - if anyone thinks it would be
useful, that is.

The majority of people don't have Rose, so a GUI tool is still needed - but
I thought it might be fruitful to show that there are other ways to create
the mapping file.

Cheers,

Charles.	


This email and any attachments are strictly confidential and are intended
solely for the addressee. If you are not the intended recipient you must
not disclose, forward, copy or take any action in reliance on this message
or its attachments. If you have received this email in error please notify
the sender as soon as possible and delete it from your computer systems.
Any views or opinions presented are solely those of the author and do not
necessarily reflect those of HPD Software Limited or its affiliates.

 At present the integrity of email across the internet cannot be guaranteed
and messages sent via this medium are potentially at risk.  All liability
is excluded to the extent permitted by law for any claims arising as a re-
sult of the use of this medium to transmit information by or to 
HPD Software Limited or its affiliates.

Re: [OJB-developers] ERROR: Server configuration denies access to data source

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

hi christian,

you can also have lazy loading relationships without having a proxy for each
object in the relationship.
simply use <proxyCollection>true</proxyCollection> in the
CollectionDescriptor :

<CollectionDescriptor id="1">
    <orderby sort="asc">saldo</orderby>
    <cdfield.name>konti</cdfield.name>
    <items.class>brj.ojb.Konto</items.class>
    <inverse_fk_descriptor_ids>2</inverse_fk_descriptor_ids>
    <auto.retrieve>true</auto.retrieve>
    <auto.update>true</auto.update>
    <auto.delete>true</auto.delete>
    <proxyCollection>true</proxyCollection>            <<<- one proxy for
the whole collection
</CollectionDescriptor>

the whole relationship can be loaded with two sqls (a count and a select).
it's also possible to combine both proxy approaches, but i think it does not
make sense (you'll end with n + 2 queries).

hth jakob

----- Original Message -----
From: "Christian Sell" <chr...@ne...>
To: "ojb" <obj...@li...>
Sent: Tuesday, February 26, 2002 7:58 PM
Subject: Re: [OJB-developers] ERROR: Server configuration denies access to
data source


Hi,

I have pounded on this before, but think its worth repeating - I think the
biggest performance risk with OJB is the way relationships are handled.
Unless something has been changed since I last looked at this, OJB first
loads the primary keys for the related objects, and then loads the data for
the individual objects one at a time. For a relationship with, say, 100
target objects, that can result in 101 SQL statements (unless objects are
already in the cache) being sent over the network. Yuck. And the proxy
"feature" does not remedy this a bit.
A JDBC programmer (and some other O/R framworks as well) will use just 1
statement and iterate the cursor.

regards,
Christian

----- Original Message -----
From: "Thomas Mahler" <tho...@ho...>
To: "Ricardo Argüello" <ri...@ya...>; "ojb"
<obj...@li...>
Sent: Tuesday, February 26, 2002 6:56 PM
Subject: Re: [OJB-developers] ERROR: Server configuration denies access to
data source


Hi Ricardo,

I don't think that OJB is slow in general. I have done several
performance comparisons against other persistence layer and native JDBC.


To argue with your boss you can do the following:
Let the OJB performance testsuite (build.sh performance) run against
your MySql DB.
YOu will definitely see that a native JDBC solution is not much faster.
(say 5 to 20 percent)


Of course performance depends a lot on you set up the mapping. The usage
of proxies is sometimes helpful. But it always depends on the special
requirements of your application.

I hope to get the proxies issues fixed by this week.

For the time beeing you might send me your repository.xml and some of
your poor performing code. I will have a look at it.

I hope this will be quick enough!

lots of greetings from Essen, Germany,

Thomas

Ricardo Argüello wrote:

> Hi Thomas,
>
> OJB is performing REALLY slow, and I'm begining to have some "problemas"
with my users...
>
> A simple insert or select takes way to much time. I don't think it is a
database problem, since MySql is very fast (because of the fact it doesn't
use transactions or referential integrity :-)
>
> I just wanted to know how long do you think it will take you to check the
dynamic proxy issue. I believe that OJB + dynamic proxies will be the
solution for my perfomance problem, but in the mean time, I'm stuck into a
very uncomfortable situation... My boss is asking me to justify the use of a
persistance layer whatsoever! He thinks straight JDBC would have been a
better solution... But there is no way I could have finished the project on
time, if it wasn't for OJB! Thanks Thomas, you have done a GREAT job. I only
need to make the system respond FAST, and maybe OJB will be used for every
project we work on, from now on...
>
> I hope to hear from you soon,
>
> Greetings from Quito, Ecuador.
>
> Ricardo Arguello
> ri...@ya...
>
>
>
> ----- Original Message -----
> From: "Thomas Mahler" <tho...@ho...>
> To: "Ricardo Argüello" <ri...@ya...>
> Cc: "Objectbridge (E-Mail)"
<obj...@li...>
> Sent: Friday, February 22, 2002 1:02 PM
> Subject: Re: [OJB-developers] ERROR: Server configuration denies access to
data source
>
>
> Hi Ricardo,
>
> Ricardo Argüello wrote:
>
>
>>Hello,
>>
>>Nope, it didn't work.
>>
>
>
>
> Mmh...
>
>
>
>>I'm still getting the same Exception when trying to get an object which
has a lot of relations with another objects.
>>
>>This is the Exception (again):
>>
>>
>
> <snip>
>
> I will have a complete code walkthrough to fix this issue.
> For the time beeing you might consider disabling the use of proxies.
>
> Did you run the performance tests? Any results that could be interesting
> for us?
> Imho, OJB won't perform bad (even without proxies) for a large range of
> scenearios.
>
> cu,
>
> thomas
>
>
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
>
>
>
>



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


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

[OJB-developers] "tests" target results against MySql

[<ri...@ya...>]

Hi,

These are the messages I get when I run the OJB "tests" target with a =
MySql database
(after following the steps in =
http://objectbridge.sourceforge.net/rdbms-support.html. Yeah, I ran the =
target twice :-)

C:\Java\ojb-0.7.343>build tests
Buildfile: build.xml

init:

prepare:

tests:
     [move] Moving 1 files to C:\Java\ojb-0.7.343\src\test\setup
using switches: -HSQLDB, -ORACLE, -MS_ACCESS, -INSTANTDB, -DB2, =
-POSTGRESQL, +MY
SQL, -INFORMIX
.
     [move] Moving 1 files to C:\Java\ojb-0.7.343\src\test\setup
     [copy] Copying 1 files to C:\Java\ojb-0.7.343\build\test\setup
     [java] [BOOT] INFO: DB url:  jdbc:mysql://localhost:3306/ojbtest
     [java] [BOOT] INFO: Driver:  Mark Matthews' MySQL Driver
     [java] [BOOT] INFO: Version: 2.0.11
     [java] [BOOT] ERROR: General error: Unknown table 'blob_test'
     [java] java.sql.SQLException: General error: Unknown table =
'blob_test'
     [java]     at org.gjt.mm.mysql.MysqlIO.sendCommand(Unknown Source)
     [java]     at org.gjt.mm.mysql.MysqlIO.sqlQueryDirect(Unknown =
Source)
     [java]     at org.gjt.mm.mysql.MysqlIO.sqlQuery(Unknown Source)
     [java]     at org.gjt.mm.mysql.Connection.execSQL(Unknown Source)
     [java] [BOOT] ERROR: Syntax error or access violation: You have an =
error in
 your SQL syntax near 'LONGVARBINARY, CLOB_VALUE_ LONGVARCHAR )' at line =
1
     [java]     at org.gjt.mm.mysql.Connection.execSQL(Unknown Source)
     [java]     at org.gjt.mm.mysql.Statement.executeUpdate(Unknown =
Source)
     [java]     at =
org.gjt.mm.mysql.jdbc2.Statement.executeUpdate(Unknown Source
)
     [java]     at ojb.broker.util.SampleThread.run(ScriptTool.java:541)
     [java]     at java.lang.Thread.run(Thread.java:484)
     [java] java.sql.SQLException: Syntax error or access violation: You =
have an
 error in your SQL syntax near 'LONGVARBINARY, CLOB_VALUE_ LONGVARCHAR =
)' at lin
e 1
     [java]     at org.gjt.mm.mysql.MysqlIO.sendCommand(Unknown Source)
     [java]     at org.gjt.mm.mysql.MysqlIO.sqlQueryDirect(Unknown =
Source)
     [java]     at org.gjt.mm.mysql.MysqlIO.sqlQuery(Unknown Source)
     [java]     at org.gjt.mm.mysql.Connection.execSQL(Unknown Source)
     [java]     at org.gjt.mm.mysql.Connection.execSQL(Unknown Source)
     [java]     at org.gjt.mm.mysql.Statement.executeUpdate(Unknown =
Source)
     [java]     at =
org.gjt.mm.mysql.jdbc2.Statement.executeUpdate(Unknown Source
)
     [java]     at ojb.broker.util.SampleThread.run(ScriptTool.java:541)
     [java]     at java.lang.Thread.run(Thread.java:484)
     [java] [BOOT] ERROR: General error: Unknown table 'ojb_nrm'
     [java] java.sql.SQLException: General error: Unknown table =
'ojb_nrm'
     [java]     at org.gjt.mm.mysql.MysqlIO.sendCommand(Unknown Source)
     [java]     at org.gjt.mm.mysql.MysqlIO.sqlQueryDirect(Unknown =
Source)
     [java]     at org.gjt.mm.mysql.MysqlIO.sqlQuery(Unknown Source)
     [java]     at org.gjt.mm.mysql.Connection.execSQL(Unknown Source)
     [java] [BOOT] ERROR: Invalid argument value: Too big column length =
for colu
mn 'OID_' (max =3D 255). Use BLOB instead
     [java]     at org.gjt.mm.mysql.Connection.execSQL(Unknown Source)
     [java]     at org.gjt.mm.mysql.Statement.executeUpdate(Unknown =
Source)
     [java]     at =
org.gjt.mm.mysql.jdbc2.Statement.executeUpdate(Unknown Source
)
     [java]     at ojb.broker.util.SampleThread.run(ScriptTool.java:541)
     [java]     at java.lang.Thread.run(Thread.java:484)
     [java] java.sql.SQLException: Invalid argument value: Too big =
column length
 for column 'OID_' (max =3D 255). Use BLOB instead
     [java]     at org.gjt.mm.mysql.MysqlIO.sendCommand(Unknown Source)
     [java]     at org.gjt.mm.mysql.MysqlIO.sqlQueryDirect(Unknown =
Source)
     [java]     at org.gjt.mm.mysql.MysqlIO.sqlQuery(Unknown Source)
     [java]     at org.gjt.mm.mysql.Connection.execSQL(Unknown Source)
     [java]     at org.gjt.mm.mysql.Connection.execSQL(Unknown Source)
     [java]     at org.gjt.mm.mysql.Statement.executeUpdate(Unknown =
Source)
     [java]     at =
org.gjt.mm.mysql.jdbc2.Statement.executeUpdate(Unknown Source
)
     [java]     at ojb.broker.util.SampleThread.run(ScriptTool.java:541)
     [java]     at java.lang.Thread.run(Thread.java:484)
     [java] [BOOT] ERROR: General error: Unknown table =
'ojb_dlist_entries'
     [java] java.sql.SQLException: General error: Unknown table =
'ojb_dlist_entri
es'
     [java]     at org.gjt.mm.mysql.MysqlIO.sendCommand(Unknown Source)
     [java]     at org.gjt.mm.mysql.MysqlIO.sqlQueryDirect(Unknown =
Source)
     [java]     at org.gjt.mm.mysql.MysqlIO.sqlQuery(Unknown Source)
     [java]     at org.gjt.mm.mysql.Connection.execSQL(Unknown Source)
     [java] [BOOT] ERROR: Invalid argument value: Too big column length =
for colu
mn 'OID_' (max =3D 255). Use BLOB instead
     [java]     at org.gjt.mm.mysql.Connection.execSQL(Unknown Source)
     [java]     at org.gjt.mm.mysql.Statement.executeUpdate(Unknown =
Source)
     [java]     at =
org.gjt.mm.mysql.jdbc2.Statement.executeUpdate(Unknown Source
)
     [java]     at ojb.broker.util.SampleThread.run(ScriptTool.java:541)
     [java]     at java.lang.Thread.run(Thread.java:484)
     [java] java.sql.SQLException: Invalid argument value: Too big =
column length
 for column 'OID_' (max =3D 255). Use BLOB instead
     [java]     at org.gjt.mm.mysql.MysqlIO.sendCommand(Unknown Source)
     [java]     at org.gjt.mm.mysql.MysqlIO.sqlQueryDirect(Unknown =
Source)
     [java]     at org.gjt.mm.mysql.MysqlIO.sqlQuery(Unknown Source)
     [java]     at org.gjt.mm.mysql.Connection.execSQL(Unknown Source)
     [java]     at org.gjt.mm.mysql.Connection.execSQL(Unknown Source)
     [java]     at org.gjt.mm.mysql.Statement.executeUpdate(Unknown =
Source)
     [java]     at =
org.gjt.mm.mysql.jdbc2.Statement.executeUpdate(Unknown Source
)
     [java]     at ojb.broker.util.SampleThread.run(ScriptTool.java:541)
     [java]     at java.lang.Thread.run(Thread.java:484)
          [java] [BOOT] ERROR: General error: Unknown table =
'ojb_dset_entries'
[java] java.sql.SQLException: General error: Unknown table =
'ojb_dset_entries'
     [java]     at org.gjt.mm.mysql.MysqlIO.sendCommand(Unknown Source)
     [java]     at org.gjt.mm.mysql.MysqlIO.sqlQueryDirect(Unknown =
Source)
     [java]     at org.gjt.mm.mysql.MysqlIO.sqlQuery(Unknown Source)
     [java]     at org.gjt.mm.mysql.Connection.execSQL(Unknown Source)
     [java]     at org.gjt.mm.mysql.Connection.execSQL(Unknown Source)
     [java]     at org.gjt.mm.mysql.Statement.executeUpdate(Unknown =
Source)
     [java]     at =
org.gjt.mm.mysql.jdbc2.Statement.executeUpdate(Unknown Source
)
     [java]     at ojb.broker.util.SampleThread.run(ScriptTool.java:541)
     [java] [BOOT] ERROR: Invalid argument value: Too big column length =
for colu
mn 'OID_' (max =3D 255). Use BLOB instead
     [java]     at java.lang.Thread.run(Thread.java:484)
     [java] java.sql.SQLException: Invalid argument value: Too big =
column length
 for column 'OID_' (max =3D 255). Use BLOB instead
     [java]     at org.gjt.mm.mysql.MysqlIO.sendCommand(Unknown Source)
     [java]     at org.gjt.mm.mysql.MysqlIO.sqlQueryDirect(Unknown =
Source)
     [java]     at org.gjt.mm.mysql.MysqlIO.sqlQuery(Unknown Source)
     [java]     at org.gjt.mm.mysql.Connection.execSQL(Unknown Source)
     [java]     at org.gjt.mm.mysql.Connection.execSQL(Unknown Source)
     [java]     at org.gjt.mm.mysql.Statement.executeUpdate(Unknown =
Source)
     [java]     at =
org.gjt.mm.mysql.jdbc2.Statement.executeUpdate(Unknown Source
)
     [java]     at ojb.broker.util.SampleThread.run(ScriptTool.java:541)
     [java]     at java.lang.Thread.run(Thread.java:484)
     [java] [BOOT] ERROR: General error: Unknown table =
'ojb_dmap_entries'
     [java] java.sql.SQLException: General error: Unknown table =
'ojb_dmap_entrie
s'
     [java]     at org.gjt.mm.mysql.MysqlIO.sendCommand(Unknown Source)
     [java]     at org.gjt.mm.mysql.MysqlIO.sqlQueryDirect(Unknown =
Source)
     [java]     at org.gjt.mm.mysql.MysqlIO.sqlQuery(Unknown Source)
     [java]     at org.gjt.mm.mysql.Connection.execSQL(Unknown Source)
     [java] [BOOT] ERROR: Invalid argument value: Too big column length =
for colu
mn 'KEY_OID' (max =3D 255). Use BLOB instead
     [java]     at org.gjt.mm.mysql.Connection.execSQL(Unknown Source)
     [java]     at org.gjt.mm.mysql.Statement.executeUpdate(Unknown =
Source)
     [java]     at =
org.gjt.mm.mysql.jdbc2.Statement.executeUpdate(Unknown Source
)
     [java]     at ojb.broker.util.SampleThread.run(ScriptTool.java:541)
     [java]     at java.lang.Thread.run(Thread.java:484)
     [java] java.sql.SQLException: Invalid argument value: Too big =
column length
 for column 'KEY_OID' (max =3D 255). Use BLOB instead
     [java]     at org.gjt.mm.mysql.MysqlIO.sendCommand(Unknown Source)
     [java]     at org.gjt.mm.mysql.MysqlIO.sqlQueryDirect(Unknown =
Source)
     [java]     at org.gjt.mm.mysql.MysqlIO.sqlQuery(Unknown Source)
     [java]     at org.gjt.mm.mysql.Connection.execSQL(Unknown Source)
     [java]     at org.gjt.mm.mysql.Connection.execSQL(Unknown Source)
     [java]     at org.gjt.mm.mysql.Statement.executeUpdate(Unknown =
Source)
     [java]     at =
org.gjt.mm.mysql.jdbc2.Statement.executeUpdate(Unknown Source
)
     [java]     at ojb.broker.util.SampleThread.run(ScriptTool.java:541)
     [java]     at java.lang.Thread.run(Thread.java:484)

BUILD SUCCESSFUL

Total time: 14 seconds
------------------------------------------------------------

I'm going to run the "performance" target tomorrow. I just wanted to =
understand why are all these exceptions about.
Looks like MySql support is broken with the defaults of the =
src\test\setup\db-setup.sql file=20

After the "successful" tests target, I tried to run the junit target and =
received 2 failures:

...   <snip> ...
    [junit] .[DEFAULT] WARN: problems with platform =
ojb.broker.platforms.Platfor
mMySQLImpl: ojb.broker.platforms.PlatformMySQLImpl
    [junit] [DEFAULT] WARN: OJB will use PlatformDefaultImpl instead
    [junit] .[DEFAULT] WARN: problems with platform =
ojb.broker.platforms.Platfor
mMySQLImpl: ojb.broker.platforms.PlatformMySQLImpl
    [junit] [DEFAULT] WARN: OJB will use PlatformDefaultImpl instead
    [junit] F
    [junit] Time: 53.888
    [junit] There were 2 failures:
    [junit] 1) =
testEscaping(test.ojb.broker.PersistenceBrokerTest)junit.framewor
k.AssertionFailedError: after inserting an object it should be equal to =
its re-r
ead pendant expected:<Single quote 'article > but was:<Single quote =
'article>
    [junit]     at =
test.ojb.broker.PersistenceBrokerTest.testEscaping(Persistenc
eBrokerTest.java:494)
    [junit] 2) =
testTimestampLock(test.ojb.broker.OptimisticLockingTest)junit.fra
mework.AssertionFailedError: Should throw an Optimistic Lock exception
    [junit]     at =
test.ojb.broker.OptimisticLockingTest.testTimestampLock(Optim
isticLockingTest.java:205)
    [junit]
    [junit] FAILURES!!!
    [junit] Tests run: 46,  Failures: 2,  Errors: 0
    [junit]

BUILD FAILED

C:\Java\ojb-0.7.343\build.xml:299: Java returned: -1

----------------------------------------------------------

I found an sql script to create the OJB internal tables for MySql in the =
sourceforge.net OJB forums while ago, and that is the schema I have been =
using before trying the new steps in the documentation. This is the =
first time I try to run the "tests" target. Besides the versioning =
tables, it looks like the schema hasn't changed, has it?

Here is the script:
http://sourceforge.net/forum/message.php?msg_id=3D1457503

I'll try to run the junit target against this schema, and post the =
results.


Aditional info:
MySql database version: 3.23.46
mm.mysql JDBC driver version: 2.0.11

Thanks in advance,

Ricardo Arguello

RE: [OJB-developers] Kill the mapping files

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

That is what Castor does. And that is pretty bloated in my humble
opinion.=20

I thought that OJB was a pure Object-Relational framework ?

/Lasse

-----Original Message-----
From: obj...@li...
[mailto:obj...@li...] On Behalf
Of Christian Sell
Sent: 27. februar 2002 00:43
To: 'ojb'
Subject: Re: [OJB-developers] Kill the mapping files


the mapping repository storage architecture should be abstracted such
that
providing specific mechanisms (XML, SQL, whatever) is a matter of
implementing a simple interface, IMO.

----- Original Message -----
From: "Lasse Lindg=E5rd" <ll...@li...>
To: "'ojb'" <obj...@li...>
Sent: Tuesday, February 26, 2002 11:42 PM
Subject: [OJB-developers] Kill the mapping files


> This might be a controversial suggestion. But it is an idea I got and
I
> would like to get some feedback on it.
>
> Wouldn't it be possible to just drop the XML mapping files.
>
> The way I see it XML files contain data. And data should be persisted
in
> a database. The way it is now the XML files are marshaled to OJB
mapping
> objects which OJB then uses to figure out how to map the objects to
> tables.
>
> If we didn't have the mapping files it would be a easier to write the
> mapping-tool since it wouldn't require you to invent a tool to marshal
> and unmarshal mapping objects to xml files.
>
> Of course for this to be possible, there would have to be some kind of
> "bootstrapping" mapping objects that map the mapping objects to
database
> tables. That could be handled with a simple factory pattern that
returns
> hardcoded prebuild mapping objects.
>
> One might argue that the current XML files are pretty simple to edit
in
> a text-editor. But I cannot see that it is significantly easier to
edit
> XML files than SQL scripts. And in the end the goal must be to build a
> visual (or better fully automatic) mapping tool.
>
> I hope my suggestion is clear enough.
> Would this be a possible way to go ?
>
> /Lasse
>
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers


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

Re: [OJB-developers] Kill the mapping files

[Christian S. <chr...@ne...>]

the mapping repository storage architecture should be abstracted such tha=
t
providing specific mechanisms (XML, SQL, whatever) is a matter of
implementing a simple interface, IMO.

----- Original Message -----
From: "Lasse Lindg=E5rd" <ll...@li...>
To: "'ojb'" <obj...@li...>
Sent: Tuesday, February 26, 2002 11:42 PM
Subject: [OJB-developers] Kill the mapping files


> This might be a controversial suggestion. But it is an idea I got and I
> would like to get some feedback on it.
>
> Wouldn't it be possible to just drop the XML mapping files.
>
> The way I see it XML files contain data. And data should be persisted i=
n
> a database. The way it is now the XML files are marshaled to OJB mappin=
g
> objects which OJB then uses to figure out how to map the objects to
> tables.
>
> If we didn't have the mapping files it would be a easier to write the
> mapping-tool since it wouldn't require you to invent a tool to marshal
> and unmarshal mapping objects to xml files.
>
> Of course for this to be possible, there would have to be some kind of
> "bootstrapping" mapping objects that map the mapping objects to databas=
e
> tables. That could be handled with a simple factory pattern that return=
s
> hardcoded prebuild mapping objects.
>
> One might argue that the current XML files are pretty simple to edit in
> a text-editor. But I cannot see that it is significantly easier to edit
> XML files than SQL scripts. And in the end the goal must be to build a
> visual (or better fully automatic) mapping tool.
>
> I hope my suggestion is clear enough.
> Would this be a possible way to go ?
>
> /Lasse
>
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

[OJB-developers] Kill the mapping files

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

This might be a controversial suggestion. But it is an idea I got and I
would like to get some feedback on it.

Wouldn't it be possible to just drop the XML mapping files.

The way I see it XML files contain data. And data should be persisted in
a database. The way it is now the XML files are marshaled to OJB mapping
objects which OJB then uses to figure out how to map the objects to
tables.

If we didn't have the mapping files it would be a easier to write the
mapping-tool since it wouldn't require you to invent a tool to marshal
and unmarshal mapping objects to xml files.

Of course for this to be possible, there would have to be some kind of
"bootstrapping" mapping objects that map the mapping objects to database
tables. That could be handled with a simple factory pattern that returns
hardcoded prebuild mapping objects.

One might argue that the current XML files are pretty simple to edit in
a text-editor. But I cannot see that it is significantly easier to edit
XML files than SQL scripts. And in the end the goal must be to build a
visual (or better fully automatic) mapping tool.

I hope my suggestion is clear enough.
Would this be a possible way to go ?

/Lasse

[OJB-developers] [PATCH] using configurable PersistenceBroker implementation

[Leandro R. S. C. <le...@ib...>]

How can I use other implementation of PersistenceBroker other than
PersistenceBrokerImpl ??

I couldn't answer this question upon rapid code examination.
Since we don't have any cvs repo to diff against I'm sending this new
version of PersistenceBrokerFactory.java and
PersistenceBrokerFactoryConfiguration.java from ojb-0.7.343
.
There is a little comment in PersistenceBrokerFactory but I didn't
implemet things that way because I would have to spend more time and
change other files and possibly break compatibility.
Any way, this changes passed /ojb-home/build.sh junit and I think they
are worth to take a look.

Any comments ?? please speak up !

-- 
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e Servicos (IB)
http://www.ibnetwork.com.br

RE: [OJB-developers] Re: Visual Tool?

[Florian B. <bf...@fl...>]

Hi,

>  >
>  > If there is no visual tool, would it be appreciated if I contributed
>  > one, written using Swing and JDK 1.4.0?
>  >
>
>
> Sure! OJB relies much on such contributions. We are not sponsored by a
> company or any other organisation.
>                 So everything (even rough code sketches, design ideas,
> contructive criticizm if definitely appreciated!
>

Then I think I have something to share here. Some time ago I started writing
a small tool that visualises a database structure. It never really left the
state of a design study, its main purpose was for me to get some insight on
the DatabaseMetadata interface. As I've seen this discussion I did some
quick hacks and it is now able to generate the XML-Mapping and the related
Java-classes (going the hard way with just doing some String concatenation).

While this code is poorly designed and without any comments it still could
maybe serve as a starting point for reverse engineering a database
structure, as this was not as easy as it seemed first. As always with JDBC,
every vendor implements the DatabaseMetadata interface differently.

If you want to use it as a starting point or just as inspiration I could
spend some time on commenting the code and I also would be more than happy
to participate in such a project.

best regards,
Florian

Re: [OJB-developers] ERROR: Server configuration denies access to data source

[Christian S. <chr...@ne...>]

Hi,

I have pounded on this before, but think its worth repeating - I think th=
e
biggest performance risk with OJB is the way relationships are handled.
Unless something has been changed since I last looked at this, OJB first
loads the primary keys for the related objects, and then loads the data f=
or
the individual objects one at a time. For a relationship with, say, 100
target objects, that can result in 101 SQL statements (unless objects are
already in the cache) being sent over the network. Yuck. And the proxy
"feature" does not remedy this a bit.
A JDBC programmer (and some other O/R framworks as well) will use just 1
statement and iterate the cursor.

regards,
Christian

----- Original Message -----
From: "Thomas Mahler" <tho...@ho...>
To: "Ricardo Arg=FCello" <ri...@ya...>; "ojb"
<obj...@li...>
Sent: Tuesday, February 26, 2002 6:56 PM
Subject: Re: [OJB-developers] ERROR: Server configuration denies access t=
o
data source


Hi Ricardo,

I don't think that OJB is slow in general. I have done several
performance comparisons against other persistence layer and native JDBC.


To argue with your boss you can do the following:
Let the OJB performance testsuite (build.sh performance) run against
your MySql DB.
YOu will definitely see that a native JDBC solution is not much faster.
(say 5 to 20 percent)


Of course performance depends a lot on you set up the mapping. The usage
of proxies is sometimes helpful. But it always depends on the special
requirements of your application.

I hope to get the proxies issues fixed by this week.

For the time beeing you might send me your repository.xml and some of
your poor performing code. I will have a look at it.

I hope this will be quick enough!

lots of greetings from Essen, Germany,

Thomas

Ricardo Arg=FCello wrote:

> Hi Thomas,
>
> OJB is performing REALLY slow, and I'm begining to have some "problemas=
"
with my users...
>
> A simple insert or select takes way to much time. I don't think it is a
database problem, since MySql is very fast (because of the fact it doesn'=
t
use transactions or referential integrity :-)
>
> I just wanted to know how long do you think it will take you to check t=
he
dynamic proxy issue. I believe that OJB + dynamic proxies will be the
solution for my perfomance problem, but in the mean time, I'm stuck into =
a
very uncomfortable situation... My boss is asking me to justify the use o=
f a
persistance layer whatsoever! He thinks straight JDBC would have been a
better solution... But there is no way I could have finished the project =
on
time, if it wasn't for OJB! Thanks Thomas, you have done a GREAT job. I o=
nly
need to make the system respond FAST, and maybe OJB will be used for ever=
y
project we work on, from now on...
>
> I hope to hear from you soon,
>
> Greetings from Quito, Ecuador.
>
> Ricardo Arguello
> ri...@ya...
>
>
>
> ----- Original Message -----
> From: "Thomas Mahler" <tho...@ho...>
> To: "Ricardo Arg=FCello" <ri...@ya...>
> Cc: "Objectbridge (E-Mail)"
<obj...@li...>
> Sent: Friday, February 22, 2002 1:02 PM
> Subject: Re: [OJB-developers] ERROR: Server configuration denies access=
 to
data source
>
>
> Hi Ricardo,
>
> Ricardo Arg=FCello wrote:
>
>
>>Hello,
>>
>>Nope, it didn't work.
>>
>
>
>
> Mmh...
>
>
>
>>I'm still getting the same Exception when trying to get an object which
has a lot of relations with another objects.
>>
>>This is the Exception (again):
>>
>>
>
> <snip>
>
> I will have a complete code walkthrough to fix this issue.
> For the time beeing you might consider disabling the use of proxies.
>
> Did you run the performance tests? Any results that could be interestin=
g
> for us?
> Imho, OJB won't perform bad (even without proxies) for a large range of
> scenearios.
>
> cu,
>
> thomas
>
>
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
>
>
>
>



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

Re: [OJB-developers] Re: Visual Tool?

[<Joa...@tp...>]

Thomas Mahler <tho...@ho...> wrote:
> Apart from providing mapping functionality (which allow to map existing
> java classes on existing RDBMS tables) we want to have forward- and
> reverse engineering features in this workbench :
> - from a Java Class model to an xml-repository and to RDBMS tables
> - from tables to classes and to an xml-repository.
> - from a xml-repository to classes and tables.

I thought about using XDoclect (http://xdoclet.sf.net/) for the first one.
XDoclet is basically a Doclet on steroids. This would allow such things as
specifing details as Java-Doc @tags. The XML2DLL is another step in this
(although it needs the ability to produce code for several different RDMS),
so this would finish point 1.

with this available there would be a need for conversion
- from tables to classes and
- from xml-repository to classes (which I think is easier).

For most of these things to be implemented nicely we'd need a final
DTD/Schema, as it would have to be reworked when the DTD changes (and from
what I read in the archive, the pending DTD change should be more than a
simple renaming of tags.)

It seems that the Discussion about a different DTD stoped without any real
changes on the core. I for one would prioritize finalizing a clean
DTD/Schema (mostly because we are just working our way into OJB and I
dislike having to re-learn stuff).

> There have been several discussions on this topic in the forums.
> There is also an outdated entry in the SourceForge TaskManager sketching
> my overall idea.
>
> There is also a contrib package on the download page
> (contrib-0.7.343.tgz). This archive contains some experimental code
> regarding DDL generation.

it seems somewhat out of date (importing classes that are no longer there).

we need to decide wether we want to use OJB or Kodo JDO rather soon
(probably tomorrow), and personally I'd prefer OJB. If OJB wins, I'll have
quite some time to work on OJB.

btw, why is CVS not mainted? is there any special reason? Are the releases
the only public updates?

regards
Joachim Sauer

[OJB-developers] Using OJB with stuctured files

[Leandro R. S. C. <le...@ib...>]

Hi all.
I'm new to OJB and I'd like to know if it is possible to use OJB as a
Persistence Layer above structured files ( xml, log files, csv files,
etc )
using interfaces like PersistenceBroker, Query, etc.

has anyone ever tried this ??

-- 
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e Servicos (IB)
http://www.ibnetwork.com.br

Re: [OJB-developers] ERROR: Server configuration denies access to data source

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

Hi Ricardo,

I don't think that OJB is slow in general. I have done several=20
performance comparisons against other persistence layer and native JDBC.


To argue with your boss you can do the following:
Let the OJB performance testsuite (build.sh performance) run against=20
your MySql DB.
YOu will definitely see that a native JDBC solution is not much faster.=20
(say 5 to 20 percent)


Of course performance depends a lot on you set up the mapping. The usage=20
of proxies is sometimes helpful. But it always depends on the special=20
requirements of your application.

I hope to get the proxies issues fixed by this week.

For the time beeing you might send me your repository.xml and some of=20
your poor performing code. I will have a look at it.

I hope this will be quick enough!

lots of greetings from Essen, Germany,

Thomas

Ricardo Arg=FCello wrote:

> Hi Thomas,
>=20
> OJB is performing REALLY slow, and I'm begining to have some "problemas=
" with my users...
>=20
> A simple insert or select takes way to much time. I don't think it is a=
 database problem, since MySql is very fast (because of the fact it doesn=
't use transactions or referential integrity :-)
>=20
> I just wanted to know how long do you think it will take you to check t=
he dynamic proxy issue. I believe that OJB + dynamic proxies will be the =
solution for my perfomance problem, but in the mean time, I'm stuck into =
a very uncomfortable situation... My boss is asking me to justify the use=
 of a persistance layer whatsoever! He thinks straight JDBC would have be=
en a better solution... But there is no way I could have finished the pro=
ject on time, if it wasn't for OJB! Thanks Thomas, you have done a GREAT =
job. I only need to make the system respond FAST, and maybe OJB will be u=
sed for every project we work on, from now on...
>=20
> I hope to hear from you soon,
>=20
> Greetings from Quito, Ecuador.
>=20
> Ricardo Arguello
> ri...@ya...
>=20
>=20
>=20
> ----- Original Message -----=20
> From: "Thomas Mahler" <tho...@ho...>
> To: "Ricardo Arg=FCello" <ri...@ya...>
> Cc: "Objectbridge (E-Mail)" <obj...@li...urceforge.=
net>
> Sent: Friday, February 22, 2002 1:02 PM
> Subject: Re: [OJB-developers] ERROR: Server configuration denies access=
 to data source
>=20
>=20
> Hi Ricardo,
>=20
> Ricardo Arg=FCello wrote:
>=20
>=20
>>Hello,
>>
>>Nope, it didn't work.
>>
>=20
>=20
>=20
> Mmh...
>=20
>=20
>=20
>>I'm still getting the same Exception when trying to get an object which=
 has a lot of relations with another objects.
>>
>>This is the Exception (again):
>>
>>
>=20
> <snip>
>=20
> I will have a complete code walkthrough to fix this issue.
> For the time beeing you might consider disabling the use of proxies.
>=20
> Did you run the performance tests? Any results that could be interestin=
g=20
> for us?
> Imho, OJB won't perform bad (even without proxies) for a large range of=
=20
> scenearios.
>=20
> cu,
>=20
> thomas
>=20
>=20
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20
>=20
>=20
>=20
>=20

[OJB-developers] Re: Visual Tool?

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

Hi Alan,

Thanks for your interest!

Alan Mellor wrote:

 > Hi,
 >
 > Great project in OJB. I have a question that I could not find answered
 > in the FAQ ( ... during the time I spent, perhaps ... )
 >


There is a roadmap document (http://objectbridge.sf.net/roadmap.html)
laying out the current status and our future plans.


 > Is the XML O/R mapping metadata entered by hand, or via a visual tool?


currently it must be edited manually. But we definitely want to have
such a tool.
I would like to something like the TOPLink mapping workbench, which
provides quite a lot of well structured engineering features.


 >
 > If there is no visual tool, would it be appreciated if I contributed
 > one, written using Swing and JDK 1.4.0?
 >


Sure! OJB relies much on such contributions. We are not sponsored by a
company or any other organisation.
                So everything (even rough code sketches, design ideas,
contructive criticizm if definitely appreciated!

Apart from providing mapping functionality (which allow to map existing
java classes on existing RDBMS tables) we want to have forward- and
reverse engineering features in this workbench :
- from a Java Class model to an xml-repository and to RDBMS tables
- from tables to classes and to an xml-repository.
- from a xml-repository to classes and tables.

There have been several discussions on this topic in the forums.
There is also an outdated entry in the SourceForge TaskManager sketching
my overall idea.

There is also a contrib package on the download page
(contrib-0.7.343.tgz). This archive contains some experimental code
regarding DDL generation.

There is also another SourceForge project (DBGen) that provides
generation of java classes from RDBMS tables.
The code generated won't match for OJB but maybe it's a good point to
start from.

thanks for your offer to help again,
cheers,

Thomas


 > Cheers,
 > Alan Mellor.
 >
 > _________________________________________________________________
 > MSN Photos is the easiest way to share and print your photos:
 > http://photos.msn.com/support/worldwide.aspx
 >
 >
 >
 >

Re: [OJB-developers] ODMG and referendial integrity

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

great news!

I just checked out your latest code and it worked !!!

Florian Bruckner wrote:

 > Hi,
 >
 > just commited some changes to CVS that makes it now possible to use
 > referential integrity. Compared to the old implementation it is now
 > guaranteed to do the following:
 >
 >   - maintain the order of lock aquisiation if no relations are known. 
This
 > makes it possible to use referential integrity constraints or for example
 > check constraints where OJB cannot resolve the dependencies
 >   - reorder objects that are related via references or collections so
 > violating foreign key constraints is prevents
 >
 > The following classes were modified:
 >
 > - test.ojb.odmg.RITest: modified testcase and associated Classes
 > - ojb.odmg.states.ModificationState, ojb.odmg.states.StateNewDelete and
 > ojb.odmg.states.StateOldDelete: Added a method needsDelete() to check
 > whether the object will be deleted (necessary for dependency resolution)
 > - ojb.broker.Identity: provides now a hashCode() and equals() to make it
 > possible to use Identity as a key in a HasMap/HashTable directly. 
Improves
 > speed compared to String representation.


good idea !


 > - ojb.odmg.ObjectEnvelope: add method needsDelete()
 > - ojb.odmg.ObjectEnvelopeTable: reorder related objects so they are
 > inserted/update/deleted in the correct order when referential integrity
 > constraints are in place while maintaining order of lock aquisition if no
 > dependencies are known. Adds a slight overhead of about 10% per locked
 > object to processing when using HSQLDB.



As HSQLDB does most the work inmemory this overhead will much smaller
for other RDBMS.

thanks for your efforts!

best regards, Thomas


 >
 > best regards,
 > Florian
 >
 >
 > _______________________________________________
 > Objectbridge-developers mailing list
 > Obj...@li...
 > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
 >
 >
 >
 >

[OJB-developers] ODMG and referendial integrity

[Florian B. <bf...@fl...>]

Hi,

just commited some changes to CVS that makes it now possible to use
referential integrity. Compared to the old implementation it is now
guaranteed to do the following:

  - maintain the order of lock aquisiation if no relations are known. This
makes it possible to use referential integrity constraints or for example
check constraints where OJB cannot resolve the dependencies
  - reorder objects that are related via references or collections so
violating foreign key constraints is prevents

The following classes were modified:

- test.ojb.odmg.RITest: modified testcase and associated Classes
- ojb.odmg.states.ModificationState, ojb.odmg.states.StateNewDelete and
ojb.odmg.states.StateOldDelete: Added a method needsDelete() to check
whether the object will be deleted (necessary for dependency resolution)
- ojb.broker.Identity: provides now a hashCode() and equals() to make it
possible to use Identity as a key in a HasMap/HashTable directly. Improves
speed compared to String representation.
- ojb.odmg.ObjectEnvelope: add method needsDelete()
- ojb.odmg.ObjectEnvelopeTable: reorder related objects so they are
inserted/update/deleted in the correct order when referential integrity
constraints are in place while maintaining order of lock aquisition if no
dependencies are known. Adds a slight overhead of about 10% per locked
object to processing when using HSQLDB.

best regards,
Florian

AW: AW: [OJB-developers] deleting objects from an m:n association

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

> -----Urspr=FCngliche Nachricht-----
> Von: Ulrich Buettgen [mailto:ubu...@ya...]
> Gesendet: Montag, 25. Februar 2002 16:26
> An: obj...@li...
> Betreff: Re: AW: [OJB-developers] deleting objects from an m:n
> association
>=20
>=20
> Hi Thomas,
> =20
> -snip-
> > If you are using m:n mappings that are transparently=20
> mapped, you can't
> > access the association as a separate entity.
> > That's why it is called transparent.
>=20
> Which is a very impressive feature! I'm using it in a way described =
in
> tutorial 3, section "Support for non-decomposed m:n mappings"=20
> as I'm not
> interested in role information.
>=20
> I can add Objects to an transparent association with a simple
>=20
>   person.getProjects().add( project);
>=20
> What I'm looking for is the reverse thing (if the person no=20
> longer belongs
> to the project):
>=20
>   person.getProjects().remove( project);
>=20
> Do I have to give up transparency for this kind of operation?
>=20

Yes ! You have to code it manually as explained in my previous mail.

Thomas

> TIA
>=20
> Uli
>=20
>=20
> __________________________________________________________________
>=20
> Gesendet von Yahoo! Mail - http://mail.yahoo.de
> Ihre E-Mail noch individueller? - http://domains.yahoo.de
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20

Re: AW: [OJB-developers] deleting objects from an m:n association

[<ubu...@ya...>]

Hi Thomas,
 
-snip-
> If you are using m:n mappings that are transparently mapped, you can't
> access the association as a separate entity.
> That's why it is called transparent.

Which is a very impressive feature! I'm using it in a way described in
tutorial 3, section "Support for non-decomposed m:n mappings" as I'm not
interested in role information.

I can add Objects to an transparent association with a simple

  person.getProjects().add( project);

What I'm looking for is the reverse thing (if the person no longer belongs
to the project):

  person.getProjects().remove( project);

Do I have to give up transparency for this kind of operation?

TIA

Uli


__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Ihre E-Mail noch individueller? - http://domains.yahoo.de

AW: [OJB-developers] deleting objects from an m:n association

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

Hi Ulrich,

> -----Urspr=FCngliche Nachricht-----
> Von: Ulrich Buettgen [mailto:ubu...@ya...]
> Gesendet: Montag, 25. Februar 2002 15:18
> An: obj...@li...
> Betreff: [OJB-developers] deleting objects from an m:n association
>=20
>=20
> Hi all,
>=20
> I'm looking for a way to delete objects from an m:n association. The
> delete Testcase in MtoNmapping.java only shows how to delete=20
> a project in
> a person<->project association but not how to delete the association
> itself (all persons and all project should remain in the database).
>=20
> Any ideas or hints?
>=20

If you are using m:n mappings that are transparently mapped, you can't
access the association as a separate entity.
That's why it is called transparent.

But you can of course define an additional class MyAssociation mapped =
on the
M:N intermediary table.=20
having this class you may add or delete association entities
programmatically!

There is a sample for an m:n association class test.ojb.broker.Role.

HTH,=20
Thomas

> TIA
>=20
> Uli
>=20
>=20
> __________________________________________________________________
>=20
> Gesendet von Yahoo! Mail - http://mail.yahoo.de
> Ihre E-Mail noch individueller? - http://domains.yahoo.de
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20

[OJB-developers] deleting objects from an m:n association

[<ubu...@ya...>]

Hi all,

I'm looking for a way to delete objects from an m:n association. The
delete Testcase in MtoNmapping.java only shows how to delete a project in
a person<->project association but not how to delete the association
itself (all persons and all project should remain in the database).

Any ideas or hints?

TIA

Uli


__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Ihre E-Mail noch individueller? - http://domains.yahoo.de

Antwort: AW: [OJB-developers] Documentation

[<Joa...@tp...>]

Hy,

first of all, sorry for the bad quoting (I have to use Lotus Notes). (And
sorry Thomas, for the duplicate, but I think this belongs to the list, and
I accidently sent it to you alone)

>> Our main problem with OJB at the moment is
>> the pretty steep learning curve.
>
> Leraning with respect to API? Mapping?

It seems the hardes part is setup, configuration and mapping, the API looks
good. (I havent looked to much into it, but a co-worker said it's easy to
use).


> Did you have a look at the document "how to setup OJB with a specific
RDBMS"
> (http://objectbridge.sourceforge.net/rdbms-support.html). This document
> explains all steps necessary to run OJB with a given DB.

I found it ... too late ;-) Initially i tried it the
"don't-read-any-documentation"-way and I thought MySQL was supported,
'cause there was some initial support in the build.xml. After I found out
that only the very basics of MySQL-support were included (and it seems that
it is out of date) it was no problem to fix it. Another iritating fact was
that builds (especially test & run_*_examples) produce lots of spurious
warnings (especially for MySQL, where every test produces 2 (or 3,
depending on the width of your terminal) lines with warnings about a
missing PlatformImpl).

All in all it seems that it's just initial problems that are overcome with
some work. But in my experience its this little problems that make people
look for other tools. (Which would be sad, 'cause aside from these OJB
looks great).

regards
Joachim Sauer

AW: [OJB-developers] Documentation

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

Hi Joachim,

> 
> Hy,
> 
> we're currently looking for a good persistance layer for our 
> project. The
> only two real candidates left are ObJectBridge and Kodo JDO. 
> ObJectBridge
> seems to have a great design and to be powerfull enough (we 
> implemented a
> prototype using Castor, but were quite disapointed by it's 
> abbilities (no
> real polymorphism for example)). Our main problem with OJB at 
> the moment is
> the pretty steep learning curve. 

Leraning with respect to API? Mapping? 

I tried the tests with MySQL 
> and it took
> quite some work to get the tests to run (and still 2 do fail, 
> but that is
> caused by MySQLs way to handle CLOBs (it strips spaces from 
> the end)). I
> understand that MySQL is not a prime target, but I think many 
> developers
> are turned away because of this. Our product should work with 
> all kinds of
> DBs, but we use MySQL for testing (along with PostgreSQL and 
> MS SQL Server
> (maybe Oracle later on)). I intend to write a walkthrough 
> from downloading
> to the first persisted class (maybe a bit more, it's intended 
> primarily for
> internal use, but I will happily contribute it if you want), because
> although the tutorials are nice, they hide a lot of work needed in
> build.xml and I think that the understanding of OBJ would be 
> greater if a
> step-by-step walkthrough would be provided.
> 

That's a great idea. OJB relies on such user contribution. We try to provide
a framework that allows to work with virtually any Rdbms.
But we can't support all datadases ourselves. (personally I'm working with
HSQLDB, DB2 and Oracle). I just don't have any MySQL Know-how.

Did you have a look at the document "how to setup OJB with a specific RDBMS"
(http://objectbridge.sourceforge.net/rdbms-support.html). This document
explains all steps necessary to run OJB with a given DB.

> One last question: it seems that supporting other Databases is just a
> matter of modifing the DDL-scripts that set up the test database and
> implementing an PlatformXXXImpl (to avoid spurious warings), is this
> correct?

Yes. (please refer again to
http://objectbridge.sourceforge.net/rdbms-support.html.
The Platform interface is currently not very useful but it will allow to get
along with all kind of RDBMS specific behaviour.

thanks for your efforts,

Thomas

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

[OJB-developers] Documentation

[<Joa...@tp...>]

Hy,

we're currently looking for a good persistance layer for our project. The
only two real candidates left are ObJectBridge and Kodo JDO. ObJectBridge
seems to have a great design and to be powerfull enough (we implemented a
prototype using Castor, but were quite disapointed by it's abbilities (no
real polymorphism for example)). Our main problem with OJB at the moment is
the pretty steep learning curve. I tried the tests with MySQL and it took
quite some work to get the tests to run (and still 2 do fail, but that is
caused by MySQLs way to handle CLOBs (it strips spaces from the end)). I
understand that MySQL is not a prime target, but I think many developers
are turned away because of this. Our product should work with all kinds of
DBs, but we use MySQL for testing (along with PostgreSQL and MS SQL Server
(maybe Oracle later on)). I intend to write a walkthrough from downloading
to the first persisted class (maybe a bit more, it's intended primarily for
internal use, but I will happily contribute it if you want), because
although the tutorials are nice, they hide a lot of work needed in
build.xml and I think that the understanding of OBJ would be greater if a
step-by-step walkthrough would be provided.

One last question: it seems that supporting other Databases is just a
matter of modifing the DDL-scripts that set up the test database and
implementing an PlatformXXXImpl (to avoid spurious warings), is this
correct?

regards
Joachim Sauer

[OJB-developers] [fyi]: Jakamar / OJB

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

> -----Urspr=FCngliche Nachricht-----
> Von: Erki Suurjaak [mailto:er...@la...]
> Gesendet: Donnerstag, 21. Februar 2002 10:49
> An: Mahler Thomas
> Betreff: Re: Jakamar / OJB
>=20
>=20
> On Tue, 19 Feb 2002, Mahler Thomas wrote:
>=20
> 	Sorry for the delay, had some trouble with the mail server.
>=20
> >I found your thesis on Jakamar on the web.=20
> 	Out of curiosity, how did you come upon it?
>=20
> >I am not that happy with your feature comparison. I don't=20
> know which OJB
> >version you have been looking at. If you check it against the =
current
> >0.7.343 version you will see that only the instantiating of=20
> persistent
> >classes is still not flexible (we still rely on a public=20
> constructor).=20
> >All other points you mention have either been solved or have=20
> never existed
> >(e.g. since version 0.1.1 we allowed compound identities,=20
> support all types
> >specified by JDBC, and allow all type for PK columns etc.)
> 	The version I used was 0.5.155. By integer type PK=20
> columns I meant
> that identity generation assumes integer type. I should have=20
> stated it=20
> more clearly. But some bigger issues, like logging, error handling,=20
> documentation, flexibility in reflection and SQL still stand, I =
think.
> 	But your point is valid - the comparison is outdated and=20
> misleading, especially because I did not, for some obscure=20
> reason, mention=20
> the version number. Since changing the contents of the thesis in the=20
> current form would not be right, I will insert a disclaimer=20
> stating that=20
> several concerns have been already cleared, and that the=20
> benchmarks are=20
> also suspect.
>=20
> >I'm very interested in sharing ideas. I am also keen to=20
> learn how you could
> >make Jakamar that fast!
> 	It was not fast. It's very difficult to say how much effort I=20
> spent on it, since I started in spring 2001, worked on it=20
> sporadically=20
> over the summer and did some long coding marathons before=20
> producing the=20
> thesis. And the bugger is still not as ready as I would like=20
> it to be :)
>=20
> >Are still working on Jakamar? Are you interested in sharing=20
> of ideas or even
> >collaboration.
> 	I am still working. I was planning to make it publicly=20
> available=20
> last year, but then I had an idea to refactor Jakamar to=20
> achieve greater=20
> flexibility and power. Namely, to have a pluggable=20
> ClassMapper that maps a=20
> class onto an RDBMS. Then the present form of mapping classes=20
> (one class=20
> to one table) would just be one case of mapping, and in=20
> addition there=20
> would be mappings between a class and several tables, or=20
> whatever kind of=20
> mapping the users wants to produce themselves.
> 	Unfortunately, this has raised some difficult issues=20
> that I have=20
> not yet managed to solve and at the moment I am stalled.
>=20
> 	It would be very beneficial to incorporate some good aspects of
> Jakamar into OJB. However, I am afraid there is a severe=20
> limit on how much
> OJB can be changed, as it's pretty big and used by many=20
> people already.
> But I'm game.
> 	I'm quite satisfied with some parts of dynamic=20
> configuration that
> Jakamar has. For example, how IdentityGenerators are created - each
> generator has an IdentityGeneratorBuilder that is fed data from the
> configuration file and finally produces a usable object. This=20
> has many=20
> advantages over simple class instantiation. I'm using the=20
> same approach=20
> for creating the ClassMappers I mentioned.
> 	ObjectFactory is a good thing, allowing greater=20
> flexibility when=20
> needed. For example, some people want to reuse objects that=20
> are no longer=20
> needed, to avoid the memory overhead.
> 	ObjectIntrospector is good layer of abstraction, because the=20
> default way of using reflection for direct manipulation might=20
> not do the=20
> trick at all times. OJB is very hard-coded into using Field objects,=20
> eliminating the possibility of invoking accessor methods, for =
example.
> 	Customizable error handling, via a pluggable=20
> ErrorHandlingPolicy,=20
> is pretty good. There is a limit, of course, on what can be done to=20
> mitigate an error, but the possibility of robust performance=20
> is pleasant.=20
> It is quite bothersome, though, to write code that has to=20
> query a policy=20
> to know what to do in case of an error.
>=20
> 	Some words on OJB's error handling. It could be better. =20
> Exceptions should be more varied. For example, Jakamar has=20
> exception types
> ConfigurationException, DataStoreException, ReflectionException, and
> InvalidQueryException, that each carry information in their=20
> type itself.
> For instance, ReflectionException signals that an exception=20
> occurred when
> manipulating object fields.
> 	Some methods in OJB throw exceptions that they shouldn't. For=20
> example,=20
> PersistenceBrokerFactory.createPersistenceBroker(String) throws=20
> exceptions like SAXException, ParserConfigurationException=20
> etc. But the=20
> user has no reason whatsoever to watch out for these exceptions, they =

> should belong to the factory's internal affairs. No method=20
> callable by the=20
> user should throw anything else but an instance of=20
> PersistenceException=20
> (or PersistenceBrokerException in OJB). Unchecked exceptions=20
> aside, of=20
> course. Another thing - in some place, OJB throws a direct=20
> instance of=20
> RuntimeException. This is most definitely bad.
> 	Some methods don't throw exceptions that they should.=20
> For example,
> PersistenceBrokerFactory.createPersistenceBroker() throws no=20
> exception,
> but performs a System.exit in case of an error. There are other =
places
> that just catch an exception, maybe log it, and that's it. This is =
not
> good.
>=20
> 	OJB uses an Iterator for a results cursor. Jakamar has a Cursor
> interface, which extends ListIterator. In this way, the user=20
> can choose
> what kind of behaviour he wants, either that of ListIterator,=20
> Iterator or
> Cursor. Java's iterators has a really bad way of navigation,=20
> Cursor has a
> better one (no mixed query and command methods).
>=20
> 	OJB has Query classes in a separate package. This is a minor=20
> inconvenience for the user who has to import another package for =
this.
>=20
>=20
> 	I would like to help with OJB, as it is a pretty=20
> component, but I=20
> don't know how.
>=20
>=20
>=20
> Erki
>=20

[OJB-developers] WG: Jakamar / OJB

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

> -----Urspr=FCngliche Nachricht-----
> Von: Erki Suurjaak [mailto:er...@la...]
> Gesendet: Donnerstag, 21. Februar 2002 10:49
> An: Mahler Thomas
> Betreff: Re: Jakamar / OJB
>=20
>=20
> On Tue, 19 Feb 2002, Mahler Thomas wrote:
>=20
> 	Sorry for the delay, had some trouble with the mail server.
>=20
> >I found your thesis on Jakamar on the web.=20
> 	Out of curiosity, how did you come upon it?
>=20
> >I am not that happy with your feature comparison. I don't=20
> know which OJB
> >version you have been looking at. If you check it against the =
current
> >0.7.343 version you will see that only the instantiating of=20
> persistent
> >classes is still not flexible (we still rely on a public=20
> constructor).=20
> >All other points you mention have either been solved or have=20
> never existed
> >(e.g. since version 0.1.1 we allowed compound identities,=20
> support all types
> >specified by JDBC, and allow all type for PK columns etc.)
> 	The version I used was 0.5.155. By integer type PK=20
> columns I meant
> that identity generation assumes integer type. I should have=20
> stated it=20
> more clearly. But some bigger issues, like logging, error handling,=20
> documentation, flexibility in reflection and SQL still stand, I =
think.
> 	But your point is valid - the comparison is outdated and=20
> misleading, especially because I did not, for some obscure=20
> reason, mention=20
> the version number. Since changing the contents of the thesis in the=20
> current form would not be right, I will insert a disclaimer=20
> stating that=20
> several concerns have been already cleared, and that the=20
> benchmarks are=20
> also suspect.
>=20
> >I'm very interested in sharing ideas. I am also keen to=20
> learn how you could
> >make Jakamar that fast!
> 	It was not fast. It's very difficult to say how much effort I=20
> spent on it, since I started in spring 2001, worked on it=20
> sporadically=20
> over the summer and did some long coding marathons before=20
> producing the=20
> thesis. And the bugger is still not as ready as I would like=20
> it to be :)
>=20
> >Are still working on Jakamar? Are you interested in sharing=20
> of ideas or even
> >collaboration.
> 	I am still working. I was planning to make it publicly=20
> available=20
> last year, but then I had an idea to refactor Jakamar to=20
> achieve greater=20
> flexibility and power. Namely, to have a pluggable=20
> ClassMapper that maps a=20
> class onto an RDBMS. Then the present form of mapping classes=20
> (one class=20
> to one table) would just be one case of mapping, and in=20
> addition there=20
> would be mappings between a class and several tables, or=20
> whatever kind of=20
> mapping the users wants to produce themselves.
> 	Unfortunately, this has raised some difficult issues=20
> that I have=20
> not yet managed to solve and at the moment I am stalled.
>=20
> 	It would be very beneficial to incorporate some good aspects of
> Jakamar into OJB. However, I am afraid there is a severe=20
> limit on how much
> OJB can be changed, as it's pretty big and used by many=20
> people already.
> But I'm game.
> 	I'm quite satisfied with some parts of dynamic=20
> configuration that
> Jakamar has. For example, how IdentityGenerators are created - each
> generator has an IdentityGeneratorBuilder that is fed data from the
> configuration file and finally produces a usable object. This=20
> has many=20
> advantages over simple class instantiation. I'm using the=20
> same approach=20
> for creating the ClassMappers I mentioned.
> 	ObjectFactory is a good thing, allowing greater=20
> flexibility when=20
> needed. For example, some people want to reuse objects that=20
> are no longer=20
> needed, to avoid the memory overhead.
> 	ObjectIntrospector is good layer of abstraction, because the=20
> default way of using reflection for direct manipulation might=20
> not do the=20
> trick at all times. OJB is very hard-coded into using Field objects,=20
> eliminating the possibility of invoking accessor methods, for =
example.
> 	Customizable error handling, via a pluggable=20
> ErrorHandlingPolicy,=20
> is pretty good. There is a limit, of course, on what can be done to=20
> mitigate an error, but the possibility of robust performance=20
> is pleasant.=20
> It is quite bothersome, though, to write code that has to=20
> query a policy=20
> to know what to do in case of an error.
>=20
> 	Some words on OJB's error handling. It could be better. =20
> Exceptions should be more varied. For example, Jakamar has=20
> exception types
> ConfigurationException, DataStoreException, ReflectionException, and
> InvalidQueryException, that each carry information in their=20
> type itself.
> For instance, ReflectionException signals that an exception=20
> occurred when
> manipulating object fields.
> 	Some methods in OJB throw exceptions that they shouldn't. For=20
> example,=20
> PersistenceBrokerFactory.createPersistenceBroker(String) throws=20
> exceptions like SAXException, ParserConfigurationException=20
> etc. But the=20
> user has no reason whatsoever to watch out for these exceptions, they =

> should belong to the factory's internal affairs. No method=20
> callable by the=20
> user should throw anything else but an instance of=20
> PersistenceException=20
> (or PersistenceBrokerException in OJB). Unchecked exceptions=20
> aside, of=20
> course. Another thing - in some place, OJB throws a direct=20
> instance of=20
> RuntimeException. This is most definitely bad.
> 	Some methods don't throw exceptions that they should.=20
> For example,
> PersistenceBrokerFactory.createPersistenceBroker() throws no=20
> exception,
> but performs a System.exit in case of an error. There are other =
places
> that just catch an exception, maybe log it, and that's it. This is =
not
> good.
>=20
> 	OJB uses an Iterator for a results cursor. Jakamar has a Cursor
> interface, which extends ListIterator. In this way, the user=20
> can choose
> what kind of behaviour he wants, either that of ListIterator,=20
> Iterator or
> Cursor. Java's iterators has a really bad way of navigation,=20
> Cursor has a
> better one (no mixed query and command methods).
>=20
> 	OJB has Query classes in a separate package. This is a minor=20
> inconvenience for the user who has to import another package for =
this.
>=20
>=20
> 	I would like to help with OJB, as it is a pretty=20
> component, but I=20
> don't know how.
>=20
>=20
>=20
> Erki
>=20

[OJB-developers] [fyi]: Jakamar / OJB

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

=20

-----Urspr=FCngliche Nachricht-----
Von: Mahler Thomas=20
Gesendet: Dienstag, 19. Februar 2002 14:25
An: 'er...@la...'
Betreff: Jakamar / OJB


Hello Erki,
=20
I found your thesis on Jakamar on the web.=20
As lead architect of the OJB O/R mapping tool I appreciate your =
positive
mentioning of OJB.
=20
I also like the clear presentation of the PersistenceBroker pattern.
=20
I found several good things in the Jakamar concepts that I would like =
to
integrate into OJB (e.g. you have factory methods in the =
PersistenceBroker
interface to obtain query objects and don't rely on a separate =
QueryFactory.
Your XML repository is also quite cleanly designed)
=20
I am not that happy with your feature comparison. I don't know which =
OJB
version you have been looking at. If you check it against the current
0.7.343 version you will see that only the instantiating of persistent
classes is still not flexible (we still rely on a public constructor).=20
All other points you mention have either been solved or have never =
existed
(e.g. since version 0.1.1 we allowed compound identities, support all =
types
specified by JDBC, and allow all type for PK columns etc.)
=20
Nevertheless I recommended your thesis as a reading material to the OJB
developer mailinglist.
=20
I'm very interested in sharing ideas. I am also keen to learn how you =
could
make Jakamar that fast!
=20
Are still working on Jakamar? Are you interested in sharing of ideas or =
even
collaboration.
=20
I have been contacted by one of the lead developers of =
jakarta.apache.org a
few days ago. They want to integrate OJB into their Application =
frameworks.
This would give an enormous impetus for OJB and all positive input is =
most
welcome!
=20
best regards,
=20
Thomas Mahler
=20

Thomas Mahler=20
Senior Consultant=20
Systemintegration - Anwendungsarchitekturen=20

ITELLIUM=20
Systems & Services GmbH=20
Theodor-Althoff-Stra=DFe 2=20
45133 Essen=20

Telefon: 0201/727-5288=20
Fax: 0201/727-4952=20
Sekretariat: 0201/727-6429=20
e-mail: tho...@it...=20

=20