objectbridge-developers Mailing List for ObJectRelationalBridge (Page 35)
Brought to you by:
thma
Menu
▾
▴
objectbridge-developers — public list for developer issues
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(14) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(33) |
Feb
(8) |
Mar
(3) |
Apr
(1) |
May
(18) |
Jun
(6) |
Jul
(15) |
Aug
(71) |
Sep
(29) |
Oct
(43) |
Nov
(77) |
Dec
(54) |
| 2002 |
Jan
(54) |
Feb
(147) |
Mar
(144) |
Apr
(163) |
May
(307) |
Jun
(240) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: <ri...@ya...> - 2002-03-01 23:47:41
|
Hello, Because of the performance problems I've had with MySQL (maybe it's a = mm.mysql JDBC driver issue, but I have no time to make more tests! My = users are gonna kill me!), I'll try to import my tables to a MS SQL = Server 2000 here in my office. I downloaded the free JDBC drivers here: http://www.microsoft.com/sql/downloads/2000/jdbc.asp (Note: the .exe installer doesn't work, just download the .tar version, = and use the 3 jars from the lib directory) Question: How can I specify the MS driver in the repository.xml file? There is no <dbms.name>MSSQL</dbms.name> entry in the documentation. Does anybody has experience using OJB + MSSQL 2k? Thanks in advance, Ricardo Arguello |
|
From: Thomas M. <tho...@ho...> - 2002-03-01 09:33:45
|
Hi Ian, Ian Lim wrote: > Hi > > Forward engineering and backward engineering. > Sounds familiar... > Sure, this is not a new invention. > What do you all think about Torque's approach ? > I don't know anything about Torque. Maybe someone (Jason ?) may explain the Torque approach and what we can learn for the forward/reverse engineering topic (or in general) from it. thanks, Thomas > Just my 2 cents thought > ========== > Ian Lim > email: mal...@ya... > homepage: http://www.webappcabaret.com/mallim > > ----- Original Message ----- > From: "Thomas Mahler" <tho...@ho...> > To: <aj...@me...> > Cc: "ojb" <obj...@li...> > Sent: Wednesday, February 27, 2002 01:41 AM > Subject: [OJB-developers] Re: Visual Tool? > > > >>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 >> > >> > >> > >> > >> >> >> >> >>_______________________________________________ >>Objectbridge-developers mailing list >>Obj...@li... >>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers >> > > > > |
|
From: Jakob B. <jbr...@ho...> - 2002-03-01 07:44:41
|
hi,
i made some tests with my sample application using ms-access over jdbc-odbc.
when using proxy collections the count-statement fails with the following
exception:
java.lang.NullPointerException
at
sun.jdbc.odbc.JdbcOdbcPreparedStatement.clearParameter(JdbcOdbcPreparedState
ment.java:1026)
at
sun.jdbc.odbc.JdbcOdbcPreparedStatement.setInt(JdbcOdbcPreparedStatement.jav
a:520)
at
sun.jdbc.odbc.JdbcOdbcPreparedStatement.setObject(JdbcOdbcPreparedStatement.
java:1133)
at
sun.jdbc.odbc.JdbcOdbcPreparedStatement.setObject(JdbcOdbcPreparedStatement.
java:1077)
at
sun.jdbc.odbc.JdbcOdbcPreparedStatement.setObject(JdbcOdbcPreparedStatement.
java:1068)
at JDBCTest.main(JDBCTest.java:34)
i was digging a little bit deeper and found the reason:
jdbc-odbc does not like the prepare statement using nativeSQL() in
StatementsForClass::prepareStatement():
...
if (!FORCEJDBC1_0)
{
// result = connection.prepareStatement(connection.nativeSQL(sql), TYPE,
CONCUR); // fails with jdbc-odbc
result = connection.prepareStatement(sql, TYPE, CONCUR);
}
else
{
result = connection.prepareStatement(connection.nativeSQL(sql));
}
...
i successfully ran the tests without nativeSQL(). so why is nativeSQL() used
here ?
thanks
jakob
|
|
From: <ll...@li...> - 2002-02-28 19:25:59
|
I maybe the XML PersistenceBrooker isn't too hard to write. Perhaps it would be possible to hook-up the "Long-term-bean-persistence" framework in jdk 1.4 with the OJB metadata interface. If not, maybe some other existing XML persistence framework might fit in. I would really like to give it a shot. I am currently under some pressure on a project deadline, so I cannot promise you anything in a near future. But I will look into it. At least with some research work. /Lasse -----Original Message----- From: obj...@li... [mailto:obj...@li...] On Behalf Of Thomas Mahler Sent: 28. februar 2002 16:37 To: Lasse Lindg=E5rd Cc: 'ojb' Subject: Re: [OJB-developers] Kill the mapping files Hi again, Lasse Lindg=E5rd wrote: > Thomas, >=20 > I think your "cost-benefit" argument is a very valid one. >=20 > The idea I have might be a good one on a longer term. But the > up-front-cost for refactoring might turn out to be too heavy. > > Still refactoring the mapping files out would eliminate the task of > changing the mapping-file format. This is a good argument. Lasse, why not give it a try and provide a little prototype showing how=20 to persist the MetaData. For the time being we can keep things simple and ignore the bootstrap=20 issues. Simply write and read a complete DescriptorRepository to/from=20 the database. A DescriptorRepository should have a uinque Name like=20 "repository-Myapp-1.2-production" >=20 > Maybe the right approach is to hope and wait for a XML > PersistenceBrooker to come along and the refactor the metadata to use > that. That would make things much easier, indeed! (Any volunteers ? ;-) ) >=20 > How about using the mapping api directly instead of using XML files. Is > that possible as OJB is constructed now ? >=20 Yes, definitely. That's what I'm always talking about. You can assemble=20 the DescriptorRepository programmatically. There is even a Method in the PersistenceBroker interface to add new (or change existing)=20 ClassDescriptors to the repository. The ojb.broker.metadata.RepositoryXmlHandler (A sax document handler)=20 shows how to use the metadata API to assemble a repository. cu, Thomas _______________________________________________ Objectbridge-developers mailing list Obj...@li... https://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: Thomas M. <tho...@ho...> - 2002-02-28 15:39:13
|
Hi Ricardo, <snip> > > Thomas, these changes to the db-setup.sql file should be included in the distribution... > I don't run MySql. Thus I can't verify The MYSql DDL others contribute. If you have a completely patched db-setup.sql that allows to pass all JUnit tests please send it to me. I will integrate it into the OJB distro. Thanks, Thomas |
|
From: Thomas M. <tho...@ho...> - 2002-02-28 15:38:02
|
Hi Ricardo, <snip> Your performance results look really bad. To give you an impression that this is not typical for OJB I have attached a zipped html document containing 3 tables. The tables contain: 1. your testresults 2. my test against MS Access 3. my test against HSQLDB The Result for HSQLDB are a bit distorted as HSQBL does most things inmemory. That's why it is so fast. But that's also why the OJB version is not that much slower (in absolute numbers) but the ratio is still 45% For MS-Access you see a more "classic" OJB effect. Native JDBC is not very fast. OJB is slower. But at a very reasonable ratio: 19% My experience with DB2 and ORACLE are similar, but I currently have no numbers available. That's why I'm really shocked by your tests. I have only a few possible explanations: 1. There have been changes between 0.7.314 (the version I used) and 0.7.343 (your version) that had major impacts on performance. I had some few runs on my machine that show that this isn't the case. 2. The JDBC driver. People have often told me how fast MySql is. But when I see the results of your native JDBC tests I think it's rather slow... Maybe that other internal problems of the MYSQL JDBC driver lead to such exorbitant results. Maybe OJB uses certain features that are not well supported. Maybe it's a good idea to share experiences with other MYSQL / OJB users to share their findings and insights. Everyone is invited to post his performance test results! I am a bit surprised about the bad performance for primary key based look up (querying1 and 2). Are you sure there is a primary key defined for the table ? 3. OJB has become slow. As you can see from my tables OJB is not "slow" in general. OJB has been carefully performance tuned in the past. But we have implemented a lot of new features that almost all have performance impacts. After finishing all 1.0 features I want to have a complete code walkthrough to implement performance improvements. > > > The results show that direct JDBC is 62.7% faster than OJB (against MySql): > > [ojb] Time: 1,393.023 > [jdbc] Time: 874.658 > > > I think I found my problem.... > > :-( > Mh, as mentioned above I don't believe that OJB is the only problem. I'd like to discuss about aceptable performance. Which factor would be acceptable for you. (For me even the native JDBC variant is definitely too slow). 20%, 40% ? It's absolutely clear that an O/R layer (regardless which concrete product) *will allways* be slower as handcoded JDBC. You get a lot of programming ease and pay it with performance. Period. Of course we will work hard to minimize this overhead. I have written the performance testsuite to make people aware of the performance impact they have for their specific environment. I'm planning to provide a document on the performance TestSuite to help people understand all the numbers. best regards, Thomas |
|
From: Thomas M. <tho...@ho...> - 2002-02-28 15:37:18
|
Hi again, Lasse Lindg=E5rd wrote: > Thomas, >=20 > I think your "cost-benefit" argument is a very valid one. >=20 > The idea I have might be a good one on a longer term. But the > up-front-cost for refactoring might turn out to be too heavy. > > Still refactoring the mapping files out would eliminate the task of > changing the mapping-file format. This is a good argument. Lasse, why not give it a try and provide a little prototype showing how=20 to persist the MetaData. For the time being we can keep things simple and ignore the bootstrap=20 issues. Simply write and read a complete DescriptorRepository to/from=20 the database. A DescriptorRepository should have a uinque Name like=20 "repository-Myapp-1.2-production" >=20 > Maybe the right approach is to hope and wait for a XML > PersistenceBrooker to come along and the refactor the metadata to use > that. That would make things much easier, indeed! (Any volunteers ? ;-) ) >=20 > How about using the mapping api directly instead of using XML files. Is > that possible as OJB is constructed now ? >=20 Yes, definitely. That's what I'm always talking about. You can assemble=20 the DescriptorRepository programmatically. There is even a Method in the=20 PersistenceBroker interface to add new (or change existing)=20 ClassDescriptors to the repository. The ojb.broker.metadata.RepositoryXmlHandler (A sax document handler)=20 shows how to use the metadata API to assemble a repository. cu, Thomas |
|
From: <mau...@ig...> - 2002-02-28 02:13:21
|
Does any body have some experience in Importing ObjectBridge to an = Eclipse Project??? |
|
From: <ri...@ya...> - 2002-02-28 00:57:07
|
Hi,
These are the results for the performance target against MySql.
------------------------------------------------------------------------
C:\Java\ojb-0.7.343>build performance
Buildfile: build.xml
init:
prepare:
main-opt:
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
performance:
[ojb] [BOOT] INFO: OJB.properties: =
file:/C:/Java/ojb-0.7.343/build/test/oj
b/OJB.properties
[ojb] .[performance] INFO:
[ojb] [DEFAULT] WARN: problems with platform =
ojb.broker.platforms.Platform
MySQLImpl: ojb.broker.platforms.PlatformMySQLImpl
[ojb] [DEFAULT] WARN: OJB will use PlatformDefaultImpl instead
[ojb] [performance] INFO: inserting 10000 Objects: 98902 msec
[ojb] [performance] INFO: updating 10000 Objects: 105662 msec
[ojb] [performance] INFO: querying 10000 Objects: 114755 msec
[ojb] [performance] INFO: querying 10000 Objects: 89769 msec
[ojb] [performance] INFO: fetching 10000 Objects: 12819 msec
[ojb] [performance] INFO: deleting 10000 Objects: 79975 msec
[ojb] [performance] INFO:
[ojb] [performance] INFO: inserting 10000 Objects: 94426 msec
[ojb] [performance] INFO: updating 10000 Objects: 108806 msec
[ojb] [performance] INFO: querying 10000 Objects: 111200 msec
[ojb] [performance] INFO: querying 10000 Objects: 36563 msec
[ojb] [performance] INFO: fetching 10000 Objects: 11797 msec
[ojb] [performance] INFO: deleting 10000 Objects: 80415 msec
[ojb] [performance] INFO:
[ojb] [performance] INFO: inserting 10000 Objects: 94056 msec
[ojb] [performance] INFO: updating 10000 Objects: 105441 msec
[ojb] [performance] INFO: querying 10000 Objects: 111100 msec
[ojb] [performance] INFO: querying 10000 Objects: 41520 msec
[ojb] [performance] INFO: fetching 10000 Objects: 12618 msec
[ojb] [performance] INFO: deleting 10000 Objects: 79564 msec
[ojb]
[ojb] Time: 1,393.023
[ojb]
[ojb] OK (1 tests)
[ojb]
[jdbc] [BOOT] INFO: OJB.properties: =
file:/C:/Java/ojb-0.7.343/build/test/oj
b/OJB.properties
[jdbc] .[performance] INFO:
[jdbc] [DEFAULT] WARN: problems with platform =
ojb.broker.platforms.Platform
MySQLImpl: ojb.broker.platforms.PlatformMySQLImpl
[jdbc] [DEFAULT] WARN: OJB will use PlatformDefaultImpl instead
[jdbc] [performance] INFO: inserting 10000 Objects: 36923 msec
[jdbc] [DEFAULT] WARN: problems with platform =
ojb.broker.platforms.Platform
MySQLImpl: ojb.broker.platforms.PlatformMySQLImpl
[jdbc] [DEFAULT] WARN: OJB will use PlatformDefaultImpl instead
[jdbc] [performance] INFO: updating 10000 Objects: 38866 msec
[jdbc] [DEFAULT] WARN: problems with platform =
ojb.broker.platforms.Platform
MySQLImpl: ojb.broker.platforms.PlatformMySQLImpl
[jdbc] [DEFAULT] WARN: OJB will use PlatformDefaultImpl instead
[jdbc] [performance] INFO: querying 10000 Objects: 88227 msec
[jdbc] [DEFAULT] WARN: problems with platform =
ojb.broker.platforms.Platform
MySQLImpl: ojb.broker.platforms.PlatformMySQLImpl
[jdbc] [DEFAULT] WARN: OJB will use PlatformDefaultImpl instead
[jdbc] [performance] INFO: querying 10000 Objects: 88548 msec
[jdbc] [DEFAULT] WARN: problems with platform =
ojb.broker.platforms.Platform
MySQLImpl: ojb.broker.platforms.PlatformMySQLImpl
[jdbc] [DEFAULT] WARN: OJB will use PlatformDefaultImpl instead
[jdbc] [performance] INFO: fetching 10000 Objects: 4847 msec
[jdbc] [DEFAULT] WARN: problems with platform =
ojb.broker.platforms.Platform
MySQLImpl: ojb.broker.platforms.PlatformMySQLImpl
[jdbc] [DEFAULT] WARN: OJB will use PlatformDefaultImpl instead
[jdbc] [performance] INFO: deleting 10000 Objects: 35721 msec
[jdbc] [performance] INFO:
[jdbc] [DEFAULT] WARN: problems with platform =
ojb.broker.platforms.Platform
MySQLImpl: ojb.broker.platforms.PlatformMySQLImpl
[jdbc] [DEFAULT] WARN: OJB will use PlatformDefaultImpl instead
[jdbc] [performance] INFO: inserting 10000 Objects: 35912 msec
[jdbc] [DEFAULT] WARN: problems with platform =
ojb.broker.platforms.Platform
MySQLImpl: ojb.broker.platforms.PlatformMySQLImpl
[jdbc] [DEFAULT] WARN: OJB will use PlatformDefaultImpl instead
[jdbc] [performance] INFO: updating 10000 Objects: 38846 msec
[jdbc] [DEFAULT] WARN: problems with platform =
ojb.broker.platforms.Platform
MySQLImpl: ojb.broker.platforms.PlatformMySQLImpl
[jdbc] [DEFAULT] WARN: OJB will use PlatformDefaultImpl instead
[jdbc] [performance] INFO: querying 10000 Objects: 85974 msec
[jdbc] [DEFAULT] WARN: problems with platform =
ojb.broker.platforms.Platform
MySQLImpl: ojb.broker.platforms.PlatformMySQLImpl
[jdbc] [DEFAULT] WARN: OJB will use PlatformDefaultImpl instead
[jdbc] [performance] INFO: querying 10000 Objects: 87145 msec
[jdbc] [DEFAULT] WARN: problems with platform =
ojb.broker.platforms.Platform
MySQLImpl: ojb.broker.platforms.PlatformMySQLImpl
[jdbc] [DEFAULT] WARN: OJB will use PlatformDefaultImpl instead
[jdbc] [performance] INFO: fetching 10000 Objects: 4947 msec
[jdbc] [DEFAULT] WARN: problems with platform =
ojb.broker.platforms.Platform
MySQLImpl: ojb.broker.platforms.PlatformMySQLImpl
[jdbc] [DEFAULT] WARN: OJB will use PlatformDefaultImpl instead
[jdbc] [performance] INFO: deleting 10000 Objects: 34670 msec
[jdbc] [performance] INFO:
[jdbc] [DEFAULT] WARN: problems with platform =
ojb.broker.platforms.Platform
MySQLImpl: ojb.broker.platforms.PlatformMySQLImpl
[jdbc] [DEFAULT] WARN: OJB will use PlatformDefaultImpl instead
[jdbc] [performance] INFO: inserting 10000 Objects: 36373 msec
[jdbc] [DEFAULT] WARN: problems with platform =
ojb.broker.platforms.Platform
MySQLImpl: ojb.broker.platforms.PlatformMySQLImpl
[jdbc] [DEFAULT] WARN: OJB will use PlatformDefaultImpl instead
[jdbc] [performance] INFO: updating 10000 Objects: 38866 msec
[jdbc] [DEFAULT] WARN: problems with platform =
ojb.broker.platforms.Platform
MySQLImpl: ojb.broker.platforms.PlatformMySQLImpl
[jdbc] [DEFAULT] WARN: OJB will use PlatformDefaultImpl instead
[jdbc] [performance] INFO: querying 10000 Objects: 86404 msec
[jdbc] [DEFAULT] WARN: problems with platform =
ojb.broker.platforms.Platform
MySQLImpl: ojb.broker.platforms.PlatformMySQLImpl
[jdbc] [DEFAULT] WARN: OJB will use PlatformDefaultImpl instead
[jdbc] [performance] INFO: querying 10000 Objects: 85663 msec
[jdbc] [DEFAULT] WARN: problems with platform =
ojb.broker.platforms.Platform
MySQLImpl: ojb.broker.platforms.PlatformMySQLImpl
[jdbc] [DEFAULT] WARN: OJB will use PlatformDefaultImpl instead
[jdbc] [performance] INFO: fetching 10000 Objects: 4958 msec
[jdbc] [DEFAULT] WARN: problems with platform =
ojb.broker.platforms.Platform
MySQLImpl: ojb.broker.platforms.PlatformMySQLImpl
[jdbc] [DEFAULT] WARN: OJB will use PlatformDefaultImpl instead
[jdbc] [performance] INFO: deleting 10000 Objects: 35411 msec
[jdbc]
[jdbc] Time: 874.658
[jdbc]
[jdbc] OK (1 tests)
[jdbc]
BUILD SUCCESSFUL
Total time: 38 minutes 9 seconds
------------------------------------------------------------------------
The results show that direct JDBC is 62.7% faster than OJB (against =
MySql):
[ojb] Time: 1,393.023
[jdbc] Time: 874.658
I think I found my problem....
:-(
Greetings,
Ricardo Arguello
|
|
From: <ll...@li...> - 2002-02-27 23:03:36
|
Thomas, I think your "cost-benefit" argument is a very valid one. The idea I have might be a good one on a longer term. But the up-front-cost for refactoring might turn out to be too heavy. Still refactoring the mapping files out would eliminate the task of changing the mapping-file format. Maybe the right approach is to hope and wait for a XML PersistenceBrooker to come along and the refactor the metadata to use that. How about using the mapping api directly instead of using XML files. Is that possible as OJB is constructed now ? -----Original Message----- From: Thomas Mahler [mailto:tho...@ho...]=20 Sent: 27. februar 2002 13:59 To: Lasse Lindg=E5rd Subject: Re: [OJB-developers] Kill the mapping files Hi Lasse, Lasse Lindg=E5rd wrote: > This might be a controversial suggestion. But it is an idea I got and I > would like to get some feedback on it. >=20 > Wouldn't it be possible to just drop the XML mapping files. >=20 Yes, this is definitely possible. The XML file is only one possible view on the ojb.broker.metadata.DescriptorReposity. In the early OJB days I build up the metadata programmatically or used a Properties file. A mapping tool should definitely only work on a DescriptorRepository=20 object and not struggle with input/output formats. following this approach it will be possible to use several input/output=20 media for the metadata (e.g. XML, Properties-file, RDBMS, Java (XML-)=20 Serialization). > The way I see it XML files contain data. And data should be persisted in > a database.=20 That's a good argument. I had also some thoughts in this direction. > 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. >=20 > 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. >=20 Unmarshalling from XML to ojb.broker.metadata is currently done by=20 ojb.broker.metadata.XmlRepositoryHandler. The only thing currently missing is a marshaller. But this is quite=20 trivial to implement. > 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. I agree. >=20 > 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. >=20 > I hope my suggestion is clear enough. > Would this be a possible way to go ? >=20 Your suggestion has one advantage: OJB metadata can be persisted in the=20 same way as "ordinary" business objects. Sure this is possible and also quite elegant. I like this kind of=20 "self-reference" ! But I see no REAL benefit apart from this: But IMHO any serious mapping tool will work with DescriptorRepository=20 (and related) objects anyway. Thus it will be faced with marshalling/unmarshalling only on=20 saving/loading repositories to work on. I think it will be simpler to write an XML marshaller than to get the=20 bootstrapping process working faultlessly. It will be difficult for OJB novices to understand what's going wrong=20 when the metadata can not be loaded. There is another possible problem: several people use multiple versions=20 of the xml repository for multipe applications they are running. Working easily with multiple versions of the repository must be made=20 possible with your approach too. You see I'm a bit ambivalent regarding you proposal. maybe we need some=20 more discussion or code experiments. May be it would be a good idea to get first experiences with persisting=20 the OJB Metadata. We could provide a DescriptorRepositoryFactory that can be configured to either unmarshall the repository from XML or to load it from RDBMS. thanks, Thomas > /Lasse >=20 >=20 > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers >=20 >=20 >=20 >=20 |
|
From: <ll...@li...> - 2002-02-27 22:46:42
|
So given that the only way to store things in OJB is a database now. Shouldn't OJB store the metadata in the database then. In the future when a PersistenceBrooker for e.g. XML becomes available. OJB could persist the metadata as XML. I just think it is a bad idea to invent a parallel persistence framework for the metadata. /Lasse -----Original Message----- From: obj...@li... [mailto:obj...@li...] On Behalf Of Thomas Mahler Sent: 27. februar 2002 14:00 To: Christian Sell Cc: 'ojb' Subject: Re: [OJB-developers] Kill the mapping files Hi Christian, Christian Sell wrote: > 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. > Exactly! A Mapping tool should not see any of these storage details! Thomas _______________________________________________ Objectbridge-developers mailing list Obj...@li... https://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: <ri...@ya...> - 2002-02-27 17:52:37
|
Florian,
I fixed the db-setup.sql file, as you suggested, but kept getting =
errors.
So, I added these type changes to those you suggested:
In OJB_DMAP_ENTRIES:
VALUE_OID to BLOB
In OJB_DMAP_ENTRIES:
KEY_OID to BLOB
VALUE_OID to BLOB
In BLOB_TEST:
CLOB_VALUE_ to LONGTEXT
(LONGCLOB, as you suggested, doesn't seem to be a valid MySql type, so I =
tried using LONGTEXT for the CLOB_VALUE_ in the BLOB_TEST column)
The tests target now runs fine!
The junit target gives me the same 2 failures I previously reported.
Thomas, these changes to the db-setup.sql file should be included in the =
distribution...
I'll run the performance target now... I'll keep you guys informed.
Thanks,
Ricardo Arguello
----- Original Message -----=20
From: "Florian Bruckner" <bf...@fl...>
To: "ojb" <obj...@li...>
Sent: Wednesday, February 27, 2002 5:03 AM
Subject: RE: [OJB-developers] "tests" target results against MySql
> Hi Ricardo,
>=20
> You can easily fix these yourself by editing the file
> src/test/setup/db-setup.sql.
>=20
> For the table blob_test change the type of the column BLOB_VALUE_ to
> LONGBLOB and of the columne CLOB_VALUE to LONGCLOB.
>=20
> For the tables ojb_nrm, ojb_dlist_entries, ojb_dset_entries the type =
of the
> column OID_ should be changed to BLOB.
>=20
> For ojb_dmap_entries the type of the column KEY_OID should be BLOB.
>=20
> Concerning the testEscaping testcase. Just looked this up in the mysql =
docs
> and there it says that the behaviour is expected. For VARCHAR columns
> trailing spaces get stripped, see also
> =
http://www.mysql.com/documentation/mysql/bychapter/manual_Reference.html#=
Col
> umn_types. Informix' behaviour is the same.
>=20
> best regards,
> Florian
>=20
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
|
|
From: Ranjan B. <ran...@fr...> - 2002-02-27 15:53:18
|
I'm interested in working on a tool as well -- JHotdraw (http://jhotdraw.sourceforge.net/) has a pretty mature approach for doing the Visio-like drawing. Ranjan |
|
From: Thomas M. <tho...@ho...> - 2002-02-27 13:49:14
|
Hi Florian, Florian Bruckner wrote: > Hi, > > while fixing the referential integrity issue in the ODMG layer I found that > Identity objects are instantiated over and over again. Instantiating objects > is one of the most expensive operations one can do in Java, first it creates > a lot overhead when instantiating such classes, then it adds overhead in the > garbage collector. > You are absolutely right. I have been thinking of a solution for this quite a while, but was afraid of maintaining a huge pool of Identities. > Once an Identity object is created, the chances it will change is very > little. Identities are immutable! > Why not store the Identity object, once it is created? VirtualProxy > and IndirectionHandler already do this, if you create an Identity the > content of the stored Identity is copied. If we added such storing > capabilities for normal objects to a, lets say, IdentityFactory, in most > cases a new instantiation could be avoided. > > If an Identity object is requested from IdentityFactory, it should first > check whether for the given object an Identity exists. If yes in a second > step it should be checked if the key values have changed. IMO we won't need step too as a client app *must not* change PK values! If yes, create a > new Identity (because Identity should be immutable, imho, so they could > still be used in HashMaps), if no just return the already existing object. > Right > Most critical for design and implementation is in my opinion avoiding memory > leaks. But I think this could be handled with WeakReference and friends. > I like your idea very much. It will definitely reduce the OJB overhead. But I think we have to very careful in designing the Identity pool. It should not grow beyond some reasonable limits. If such care is taken this will be an enourmous performance boost! cu, Thomas > Any comments? > > lG, > Florian > > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > > > > |
|
From: Thomas M. <tho...@ho...> - 2002-02-27 13:49:08
|
Hi Charles & Fernando, Carles Rico wrote: > Hello, > > We are testing objectbridge, for we intend to use it in our aplication. thanks, for your interest. > We have some questions about > the mapping associations. We need to express an association ( for > instance 1:n or 1:1 ) between two fields which are not primary keys. > Can I do this with ObjectBridge? If so, how? Depends! OJB automatically maps foreign keys (in the detail) on primary keys (in the master table). OJB does not check if a field is a primary key in the database. It is sufficient to declare it as PK in the xml repository. So, if it is safe to use your non-PK column as a PK column (i.e. its values are unique accross the table) it will be possible to use OJB for this scenario. Are you going to implement > this in the future? There have been no request in this direction until now. I don't think that it will get high priority on the todo list as this situation clearly violates basic ER design principles. > In case there > was need for it, we would be willing to help you with the implementation. > thanks for your offer to help! If you implement this kinf of thing I will integrate it into the distribution, thanks, Thomas > Best regards, > > > Carles & Fernando. > > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > > > > |
|
From: Thomas M. <tho...@ho...> - 2002-02-27 13:25:52
|
Hi Christian, Christian Sell wrote: > 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. > Exactly! A Mapping tool should not see any of these storage details! Thomas |
|
From: Thomas M. <tho...@ho...> - 2002-02-27 13:24:39
|
Hi Leandro, Leandro Rodrigo Saad Cruz wrote: > How can I use other implementation of PersistenceBroker other than > PersistenceBrokerImpl ?? > currently not provided. You have to patch the PersistenceBrokerFactory, as you alerady discovered. > 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 Since about a week CVS is up again. There is a new cvs project ojb-1-0 containing the latest developement branch. This is not documented on the web page yet, as the webpage is changed only for each new release. > 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 ! > > This is definitely a feature I wanted to have for a long time. I will have a look at your code and integrate your stuff! thanks, Thomas |
|
From: Thomas M. <tho...@ho...> - 2002-02-27 13:24:38
|
Hi Leandro, Leandro Rodrigo Saad Cruz wrote: > 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 ?? > The PersistenceBroker Interface (and the Query API) has been designed as a generic interface to persistent media. Currently OJB does only contain an implementation for RDMBS. But it should be quite straightforward to build a structured file implementation. In my company we have used the OJB query mechanism to provide access against OJB, TOPLink and LDAP. hth, Thomas |
|
From: Thomas M. <tho...@ho...> - 2002-02-27 13:24:38
|
Hi again Charles, Charles Anthony wrote: <snip> > > 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. > Yes of course this may be useful. We now have a contributions archive for each release that contains stuff that is not part of the official OJB distribution (i.e. not maintained by us). I think it will be the ideal place for your scripts. > 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. > right! Some time ago someone (sorry, I don't remember his name right now) send me a patched version of ArgoUML (OpenSource UML tool) that could generate everything from an UML model. This was definitely a good approach, but unfortunately ArgoUML did not provide a plugin mechanism which would allow to distribute a small plugin an not a complete sourcelevel patched ArgoUML. cu, Thomas |
|
From: Thomas M. <tho...@ho...> - 2002-02-27 13:24:21
|
Hi Lasse,
When I got Christian right he is only talking about storing metadata=20
("mapping repository storage") not about persisting ordinary business dat=
a.
Lasse Lindg=E5rd wrote:
> That is what Castor does. And that is pretty bloated in my humble
> opinion.=20
>=20
Castor does provide XML and LDAP persistence for ordinary business data=20
too. I guess that's the reason why it's bloated.
> I thought that OJB was a pure Object-Relational framework ?
>=20
Definitely!
But there are already people working on PersistenceBroker=20
implementations that provide persistence against file formats (xml, csv,=20
etc.).
cu,
Thomas
> /Lasse
>=20
> -----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
>=20
>=20
> 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.
|
|
From: Thomas M. <tho...@ho...> - 2002-02-27 13:24:20
|
Hi Joachim, Joa...@tp... wrote: > 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. > good idea ! > 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). > You are absolutely right. That's why finalizing of the DTD (or switching to an XSD) is a todo for the 1.0 release. And mapping tool only for 2.0. I think the learning curve between the two grammars won't be too big, as there are only syntactical changes. To make the migration smooth for OJB users I want to provide a stylesheet to allow automatic translation from old to new format. > >>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). > Yes, it's from about August 2001. > we need to decide wether we want to use OJB or Kodo JDO rather soon > (probably tomorrow), and personally I'd prefer OJB. Even without JDO support? How will you decide? Did you have a full product evaluation including writing simple prototypes? Or just feature comparison. It would be quite interesting for me to see how Kodo compares to OJB as I have never seen it. If OJB wins, I'll have > quite some time to work on OJB. That would be great! > btw, why is CVS not mainted? is there any special reason? Are the releases > the only public updates? > I had big problems with developer dicipline. People checked in code that: - did not compile - produced errors in JUnit tests - imported classes from jars that were not part of the OJB distribution - did not merge sources but just overwrote changes of others. That's why I shut down cvs some time ago. BUT: In the last weeks I have been contacted by several developers who urged me to open up CVS again. Since last week it's up again (but it's not yet documented on the home page). The current development project is ojb-1-0. I will publish a list of simple "rules of conduct" to reduce the above mentioned problems. thanks, Thomas > regards > Joachim Sauer > > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > > > > |
|
From: Florian B. <bf...@fl...> - 2002-02-27 11:00:28
|
Hi, while fixing the referential integrity issue in the ODMG layer I found that Identity objects are instantiated over and over again. Instantiating objects is one of the most expensive operations one can do in Java, first it creates a lot overhead when instantiating such classes, then it adds overhead in the garbage collector. Once an Identity object is created, the chances it will change is very little. Why not store the Identity object, once it is created? VirtualProxy and IndirectionHandler already do this, if you create an Identity the content of the stored Identity is copied. If we added such storing capabilities for normal objects to a, lets say, IdentityFactory, in most cases a new instantiation could be avoided. If an Identity object is requested from IdentityFactory, it should first check whether for the given object an Identity exists. If yes in a second step it should be checked if the key values have changed. If yes, create a new Identity (because Identity should be immutable, imho, so they could still be used in HashMaps), if no just return the already existing object. Most critical for design and implementation is in my opinion avoiding memory leaks. But I think this could be handled with WeakReference and friends. Any comments? lG, Florian |
|
From: Carles R. <car...@am...> - 2002-02-27 10:31:25
|
Hello, We are testing objectbridge, for we intend to use it in our aplication. We have some questions about the mapping associations. We need to express an association ( for instance 1:n or 1:1 ) between two fields which are not primary keys. Can I do this with ObjectBridge? If so, how? Are you going to implement this in the future? In case there was need for it, we would be willing to help you with the implementation. Best regards, Carles & Fernando. |
|
From: Florian B. <bf...@fl...> - 2002-02-27 10:03:42
|
Hi Ricardo, You can easily fix these yourself by editing the file src/test/setup/db-setup.sql. For the table blob_test change the type of the column BLOB_VALUE_ to LONGBLOB and of the columne CLOB_VALUE to LONGCLOB. For the tables ojb_nrm, ojb_dlist_entries, ojb_dset_entries the type of the column OID_ should be changed to BLOB. For ojb_dmap_entries the type of the column KEY_OID should be BLOB. Concerning the testEscaping testcase. Just looked this up in the mysql docs and there it says that the behaviour is expected. For VARCHAR columns trailing spaces get stripped, see also http://www.mysql.com/documentation/mysql/bychapter/manual_Reference.html#Col umn_types. Informix' behaviour is the same. best regards, Florian |
|
From: Christian S. <nc-...@ne...> - 2002-02-27 09:38:38
|
Lasse, you got me wrong. I did not mean to let OJB map to XML as it does to RDBMS. All I tried to say is that the storage = mechanism for the *mapping repository* should be adaptable, = so that the mapping information can be stored either in the = way it is now, or in the way you propose. regards. ---- Original m= essage ---- >Datum: Wed, 27 Feb 2002 07:07:28 +0100 >Von: Lasse Lindg=E5= rd <ll...@li...> = >Betreff: RE: [OJB-developers] Kill the mapping files = >An: "'ojb'" <obj...@li...> > >That i= s what Castor does. And that is pretty bloated in my = humble >opinion. = > >I thought that OJB was a pure Object-Relational framework ? > >/La= sse > >-----Original Message----- >From: objectbridge-developers-admi= n...@li... >[mailto:obj...@li...= urceforge.net] = On Behalf >Of Christian Sell >Sent: 27. februar 2002 00:43 >To: 'ojb'= >Subject: Re: [OJB-developers] Kill the mapping files > > >the mapp= ing repository storage architecture should be = abstracted such >that >providing specific mechanisms (XML, SQL, whatev= er) is a = matter of >implementing a simple interface, IMO. > >----- Original Me= ssage ----- >From: "Lasse Lindg=E5rd" <ll...@li...> >To: "'ojb'" <obj= ect...@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. >> >> Wo= uldn't it be possible to just drop the XML mapping files. >> >> The wa= y I see it XML files contain data. And data should = be persisted >in >> a database. The way it is now the XML files are ma= rshaled = to OJB >mapping >> objects which OJB then uses to figure out how to ma= p the = objects to >> tables. >> >> If we didn't have the mapping files it wo= uld 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 fa= ctory = pattern that >returns >> hardcoded prebuild mapping objects. >> >> O= ne might argue that the current XML files are pretty = simple to edit >in >> a text-editor. But I cannot see that it is signi= ficantly = 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 wa= y to go ? >> >> /Lasse >> >> >> ___________________________________= ____________ >> Objectbridge-developers mailing list >> Objectbridge-d= eve...@li... >> https://lists.sourceforge.net/lists/= listinfo/objectbridge- developers > > >_____________________________= __________________ >Objectbridge-developers mailing list >Objectbridge= -de...@li... >https://lists.sourceforge.net/lists/= listinfo/objectbridge- developers > > >_____________________________= __________________ >Objectbridge-developers mailing list >Objectbridge= -de...@li... >https://lists.sourceforge.net/lists/= listinfo/objectbridge- developers -- = NetMail powered by NetCologne |
9 messages has been excluded from this view by a project administrator.
