objectbridge-developers Mailing List for ObJectRelationalBridge (Page 54)
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: David F. <dw...@la...> - 2001-07-24 13:07:45
|
Does anyone have an example of configuring OJB with other databases? I tried to configure the junit test to use MSAccess and it fails to even find the JDBC Driver although I can use that driver in other apps just fine. Thanks, David W. Forslund dw...@la... Computer and Computational Sciences http://www.acl.lanl.gov/~dwf Los Alamos National Laboratory Los Alamos, NM 87545 505-665-1907 FAX: 505-665-4939 |
|
From: <joe...@ya...> - 2001-07-16 15:29:23
|
Hi!
I'm a newbie with OBjectBride, and I have the
following question:
Suppose you have a tree data structure composed of the
SAME classes
*
-----|-------
| |
* *
There you have 3 classes (*) and each class in the
tree has an attribute ID for the primary key.
To avoid 3 SQL statement to load the datas, you can
use the statement 'SELECT ...where id= .. or id=.. or
id=..'
Is this possible to use this king of optimisation with
objectBridge ???
Of you, transparently, otherwise it's like to code all
with the JDBC API.
Thanks
Joel
=====
___________________________________________________________
Do You Yahoo!? -- Vos albums photos en ligne,
Yahoo! Photos : http://fr.photos.yahoo.com
|
|
From: Mahler T. <tho...@it...> - 2001-07-09 06:19:32
|
Hi all, attached you find Actional's answer to my last eMail. I did not believe they would change their mind, but I did not want to give up without confronting them with a "common sense" point of view. After reading about the trademark issues between ADOBE and the Developer of KDE Killustrator (see: http://slashdot.org/articles/01/07/04/013249.shtml), I think it's now time to tell them that I'm willing to change the name. I don't feel like paying $ 2000 for contributing an open source solution ;-( Here is my latest suggestion for a new name: ObJectRelationalBridge. - It is definitely different from Objectbridge - but close to the original name - it is even more precise than the old name - it can still be abbreviated to OJB - I did not find any usages of this term on the Web or in Usenet If there are any objections against this name, please tell me today, as I want to give a response to Actional by tomorrow. best regards, THomas -------- Original Message -------- Subject: RE: Use of term "Objectbridge" Date: Thu, 5 Jul 2001 15:24:53 -0700 From: "Linda" <li...@ac...> Reply-To: <li...@ac...> To: "Thomas Mahler" <tho...@ho...> Dear Thomas, Thank you for the response. I understand that this is a volunteer project and wish you well in the development of your software. Unfortunately, we do consider that use of the name "ObJectBridge" would be considered a trademark infringement under the Lanham Act, Section 1114. Even though you will not be charging money for your software, it still would (and will) be considered a product that is distributed to the public. Also, we believe since the name is nearly identical (the capitalization change does not make it truly different), our products are similar, and some of our users may be in similar fields, the use of the ObjectBridge name for your software would likely cause confusion or possible mistake. Since the point of trademarking is to avoid confusion in the marketplace, we believe there is possible confusion in your use of the name ObJectBridge. Because of this, we would like to ask you to please find another name to use other than ObJectBridge. Unfortunately, we must insist on this. I understand this may take some time per your email. Please email or call if you have any questions. Good luck with your work. Regards, Linda ****************************** Linda Whillock Contracts Manager Actional Corporation 701 N. Shoreline Blvd. Mountain View, CA 94043 650.254.4117 (Phone) 650.254.4101 (Fax) li...@ac... <mailto:li...@ac...> Actional delivers a high-performance integration architecture that works with your existing systems and applications, without adding new middleware. Actional's Control Broker platform allows you to utilize enterprise services across hundreds of applications with broad support for industry standards like XML, Java, EJB, COM, and CORBA. |
|
From: Mike I. <mi...@co...> - 2001-07-06 06:52:49
|
Hi Thomas, I hope this would be helpful: http://slashdot.org/articles/01/07/04/013249.shtml > -----Original Message----- > From: obj...@li... > [mailto:obj...@li...]On > Behalf Of Thomas Mahler > Sent: Wednesday, January 01, 1997 3:20 AM > To: objectbridge > Subject: [Objectbridge-developers] trademark conflict > > > Hi all, > > Thanks for all you contributions to my trademark problem. I see a > Problem with names like ObjectMap, Continuum, etc. > > We don't have resources to have a rocksolid proof that such a name is > not trademarked by someone already. If we don't register a trademark on > such a name we have no legal options against companies registering this > name as their trademark later, have we? > > I would prefer to keep the abbreviation OJB, as it used in all package > names, most documents etc. > Can natural family names be trademarked? > So I thought of Family names that could be condensed to OJB. > And I found: Ojilby. It seems to be a Venezuelan family name. It's > short, clear and sounds exotic. > > Could this be a solution for the trademark problem? > What do you think? > > best regards, > > > Thomas > > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > http://lists.sourceforge.net/lists/listinfo/objectbridge-developers > |
|
From: Thomas M. <tho...@ho...> - 2001-07-05 17:53:44
|
Dear Linda, We did not intent to conflict with your trademark. "ObJectBridge" (note: it is not spelled "Objectbridge", "ObjectBridge" or "Object Bridge") is a non-commercial OpenSource project driven by an international developer community, mediated by SourceForge.net. It is not a "Product" according to the conventional notion: There is no Vendor, there is no Product that is sold to customers, etc. Can there be a trademark conflict without two Vendors trading two Products under the same name? I'm not a lawyer but I don't see a conflict here?! We will of course change the Name of our Project if you insist. We had some internal discussion's on alternative names but did not come to a final conclusion. It will take us a while to change all Documents, sources and graphics as we all are only vonlunteering on this project. best regards, Thomas Mahler And we will of course change ou Linda wrote: > > Dear Mr. Mahler, > > I noticed that you have used the name Objectbridge for your > software. Unfortunately the name Object bridge was > trademarked on 6/23/96 by Visual Edge Software and has been > in use regularly as our product name. You can confirm this > through the patent and trademark office's website. I > noticed that your product is in beta version still and hope > you might be able to please chose another name for your > product which would not conflict with ours. > > Many thanks for your cooperation in this. You can reach me > at li...@ac... (or visit our website at > actional.com). Actional Corporation was formerly Visual > Edge Software. > > -- Linda > > |
|
From: Thomas M. <tho...@ho...> - 2001-07-05 17:51:53
|
Hi all, Thanks for all you contributions to my trademark problem. I see a Problem with names like ObjectMap, Continuum, etc. We don't have resources to have a rocksolid proof that such a name is not trademarked by someone already. If we don't register a trademark on such a name we have no legal options against companies registering this name as their trademark later, have we? I would prefer to keep the abbreviation OJB, as it used in all package names, most documents etc. Can natural family names be trademarked? So I thought of Family names that could be condensed to OJB. And I found: Ojilby. It seems to be a Venezuelan family name. It's short, clear and sounds exotic. Could this be a solution for the trademark problem? What do you think? best regards, Thomas |
|
From: Mike I. <mi...@co...> - 2001-07-04 11:24:13
|
Hey, what about name "Continuum". I never seen any OR-mapper or (O|R)DBMS with such name before! Mike |
|
From: Mike I. <mi...@co...> - 2001-07-03 07:52:28
|
Hello, well, OJB looks like something that establishes connection between worlds. There are various aspects of "connection": 1. connection, link, tie, nexus, liaison, yoke 2. ambassador, consul, nuncio, Roosevelt (Eleanor), Columbus, Marko Polo, etc 3. tunnel, aisle, corridor, drift 4. catch, clasp, cleat, cotter and other related stuff 5. rope, line, lace, sash... 6. something else :-) So, there are names synthesised from the words above: ObjectConnect, ONE (Object NExus), Eleanor, JMarko, ObjectDrift, ROPE (Relational-Object Persistence Environment), BlackTie... Your variants? Mike > Maybe ObJect Map (OJM)? > > Companies in the MQ business likes to use the word 'bridge' to > signify some > kind of cross-platform messaging adapter (that goes between say EJB and > PeopleSoft or something). > > Or how about MOJO? > |
|
From: Richard K. <ric...@he...> - 2001-07-02 19:11:45
|
Hi Thomas, Maybe ObJect Map (OJM)? Companies in the MQ business likes to use the word 'bridge' to signify some kind of cross-platform messaging adapter (that goes between say EJB and PeopleSoft or something). Or how about MOJO? Regards and best wishes, Rich Katz Tomorrow's Java Skyline -----Original Message----- From: Mahler Thomas [mailto:tho...@it...] Sent: Monday, July 02, 2001 3:10 AM To: Objectbridge (E-Mail) Subject: [Objectbridge-developers] ObJectBridge trademark conflict Hi all, I have been contacted by the company actional. They have a trademark for the name "Objectbridge" and asked me to change the name of our "product". See quoted mail below. I think I will not help to argue that there is no trademark conflict with things like: - OJB is not a "product" - "ObJectBridge" is syntactically different from "Object bridge" or "Objectbridge" Do you have any Ideas? If we are forced to change the name do you have any suggestions? here are my : - ObJect's bridge - ObJectBridges - ObJectRelationalBridge - JavaBridge regards, Thomas > -------- Original Message -------- > Subject: Use of term "Objectbridge" > Date: Fri, 29 Jun 2001 16:54:51 -0700 > From: Linda <li...@ac...> > To: tho...@ho... > > Dear Mr. Mahler, > > I noticed that you have used the name Objectbridge for your > software. Unfortunately the name Object bridge was > trademarked on 6/23/96 by Visual Edge Software and has been > in use regularly as our product name. You can confirm this > through the patent and trademark office's website. I > noticed that your product is in beta version still and hope > you might be able to please chose another name for your > product which would not conflict with ours. > > Many thanks for your cooperation in this. You can reach me > at li...@ac... (or visit our website at > actional.com). Actional Corporation was formerly Visual > Edge Software. > > -- Linda > _______________________________________________ Objectbridge-developers mailing list Obj...@li... http://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: Christian S. <chr...@ne...> - 2001-07-02 16:08:23
|
I had been wondering from the outset that this name was still available.. I would suggest keeping this topic open for a while, until a really good solution is found. ----- Original Message ----- From: "Mahler Thomas" <tho...@it...> To: "Objectbridge (E-Mail)" <obj...@li...> Sent: Monday, July 02, 2001 12:09 PM Subject: [Objectbridge-developers] ObJectBridge trademark conflict > Hi all, > > I have been contacted by the company actional. They have a trademark for the > name "Objectbridge" and asked me to change the name of our "product". > See quoted mail below. > > I think I will not help to argue that there is no trademark conflict with > things like: > - OJB is not a "product" > - "ObJectBridge" is syntactically different from "Object bridge" > or "Objectbridge" > > Do you have any Ideas? > > If we are forced to change the name do you have any suggestions? > here are my : > - ObJect's bridge > - ObJectBridges > - ObJectRelationalBridge > - JavaBridge > > regards, > > Thomas > > > -------- Original Message -------- > > Subject: Use of term "Objectbridge" > > Date: Fri, 29 Jun 2001 16:54:51 -0700 > > From: Linda <li...@ac...> > > To: tho...@ho... > > > > Dear Mr. Mahler, > > > > I noticed that you have used the name Objectbridge for your > > software. Unfortunately the name Object bridge was > > trademarked on 6/23/96 by Visual Edge Software and has been > > in use regularly as our product name. You can confirm this > > through the patent and trademark office's website. I > > noticed that your product is in beta version still and hope > > you might be able to please chose another name for your > > product which would not conflict with ours. > > > > Many thanks for your cooperation in this. You can reach me > > at li...@ac... (or visit our website at > > actional.com). Actional Corporation was formerly Visual > > Edge Software. > > > > -- Linda > > > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > http://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: Mahler T. <tho...@it...> - 2001-07-02 10:10:59
|
Hi all, I have been contacted by the company actional. They have a trademark for the name "Objectbridge" and asked me to change the name of our "product". See quoted mail below. I think I will not help to argue that there is no trademark conflict with things like: - OJB is not a "product" - "ObJectBridge" is syntactically different from "Object bridge" or "Objectbridge" Do you have any Ideas? If we are forced to change the name do you have any suggestions? here are my : - ObJect's bridge - ObJectBridges - ObJectRelationalBridge - JavaBridge regards, Thomas > -------- Original Message -------- > Subject: Use of term "Objectbridge" > Date: Fri, 29 Jun 2001 16:54:51 -0700 > From: Linda <li...@ac...> > To: tho...@ho... > > Dear Mr. Mahler, > > I noticed that you have used the name Objectbridge for your > software. Unfortunately the name Object bridge was > trademarked on 6/23/96 by Visual Edge Software and has been > in use regularly as our product name. You can confirm this > through the patent and trademark office's website. I > noticed that your product is in beta version still and hope > you might be able to please chose another name for your > product which would not conflict with ours. > > Many thanks for your cooperation in this. You can reach me > at li...@ac... (or visit our website at > actional.com). Actional Corporation was formerly Visual > Edge Software. > > -- Linda > |
|
From: Thomas M. <tho...@ho...> - 2001-06-02 11:38:38
|
Hi Steven, Thanks for your interest! "Melzer, Steven" wrote: > > Hello, my name is Steven Melzer and I am new to both ObjectBridge and > persistence in general. I have been looking for a persistence solution for > our web based database storage. We are an Oracle shop using Weblogic as our > application server. I downloaded ObjectBridge and built a very simple > example using MySQL on my local machine at home. It worked well. But I > have several questions when it comes to integrating it with WebLogic: > > 1) It seems that the ConnectionManager holds its own pool of connections. I > wish to use WebLogic's DataSource as a connection pool. I can see how to > change the source to do this, but i did not want to modify core code without > some feedback. > I think it won't be a big help to rewrite the StatementManager to use a DataSource pool. If you have a look at the source of StatementManager::getStatementForClass(...) you will see that we have one StatementsForClass instance per persistent class (or ClassDecriptor to be exact). each instance keeps for PreparedStatements for permanent reuse: - selectByPkStmt - insertStmt - updateStmt - deleteStmt To keep these statements "hot" implies to keep the underlying connections permanently open. Thus a ConnectionPool would not be of any use. That's why there is no Connection.close() anywhere. (Maybe I should put it into some finalizers, but until now this produced no problems.) I chose this design to get a maximum performance by only preparing those Statements once and resusing them later. Of course you can easily change ConnectionManager and StatementsForClass together to use your ConnectionPool. In fact OJB had such a ConnectionPool at some earlier point in time. > 2) The ConnectionManager is a singleton class holding connections. However, > I never see these connection being released anywhere. I check > StatementForClass and StatementManager, but I cannot find a > connection.close(). If the connection is maintained in the > ConnectionManager and never released, then the entire application in > WebLogic will share the same connections. If our app has hundreds of > simultaneous users, then the single connection is going to be a major > bottleneck. This goes back to the first question above. > In my eyes the bottleneck with the current design of OJB is the PersistenceBrokerImpl itself. If you have a look at PersistenBrokerImpl.beginTransaction() you will easily see that it can only perform one Transaction at a time. And as it is a singleton instance this will be the true bottleneck! If you use the odmg implementation this bottleneck situation will be reduced, as it opens broker transactions only for a very short period of time. But if you confront it with really heavy load it will od course have the same problem... The bad news: right now OJB does NOT scale! So you will need some load testing whether it can be savely used in your environment or not. I have been using OJB with IBM WebSphere with only 5-10 concurrent users without specific problems! The good news: I'm just finished with the 0.5 release which completed the ODMG API. My next deliverable is a scalable distributed architecture for OJB. This will of course take a while... By the way: - are you planning to use EntityBeans. If so you might have a look at my BMP sample code in package test.ojb.ejb! - Are there any special reasons why don't you use WebLogics standard persistence framework TopLink? best regards, Thomas Mahler > thanks in advance, > steve > > Steven Melzer > E-Business Technology > 813.351.2215 > ste...@pa... > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > http://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: Thomas M. <tho...@ho...> - 2001-06-02 07:27:31
|
Hi David, hi Sascha,
thanks for the bug fix!
I will include the fix (and a corresponding unit test) in the next
release.
I did not discover this bug earlier because I composed such statements
just the other way round (like STATE = 3 AND (ID = 10 OR ID = 12)) which
works quite well...
Thanks again,
Thomas
David Forslund wrote:
>
> Sascha has arrived at the solution to the problem we posted.
>
> There is a problem in the SqlGenerator with the priority of AND and
> OR.
> In SqlGenerator we need to "wrap" the prior generated statement with
> parentheses to make the logic correct:
>
> switch (pc.getType())
> {
> case (Criteria.OR):
> {
> statement.append( " OR
> " + addAtStart);
> statement.append(asSQLStatement(pc,
> cld));
> statement.append(addAtEnd);
> break;
> }
> case (Criteria.AND):
> {
> statement.insert(0,"(
> ");
> statement.append( ")
> ");
> statement.append(" AND
> "+addAtStart);
> statement.append(asSQLStatement(pc,
> cld));
> statement.append(addAtEnd);
> break;
> }
>
> And further down:
> SelectionCriteria c =
> (SelectionCriteria) o;
> if (statement.length() == 0)
> {
> statement.append(asSQLClause(c,
> cld));
> }
> else
> {
> statement.insert(0,"(");
> statement.append(") ");
> statement.append(" AND ");
> statement.append(asSQLClause(c,
> cld));
> }
>
> Apparently there are no junit tests for any complex queries, which
> should have uncovered this problem.
> This is still a problem in the just released 0.5.136 version.
>
> Dave
> At 12:11 PM 6/1/2001 -0600, David Forslund wrote:
>
> > We have encountered a problem with Objectbridge and are working on a
> > solution, but don't have it yet. We have a query with our search
> > filters in which we combine them together. We have something like:
> >
> > ID = 10 OR ID = 12 AND (STATE = 3)
> >
> > generated by OJBSearchFilter. However this apparently is equivalent
> > to:
> > ID=10 OR (ID = 12 AND STATE = 3)
> >
> > rather than (ID = 10 OR ID=12) AND (STATE = 3)
> >
> > It seems that when SqlGenerator checks the isEmbraced flag, it never
> > uses it for the top level Criteria.
> >
> > I'm not sure of the proper fix at this point.
> >
> > David W. Forslund dw...@la...
> > Computer and Computational
> > Sciences http://www.acl.lanl.gov/~dwf
> > Los Alamos National Laboratory Los Alamos, NM
> > 87545
> > 505-665-1907 FAX: 505-665-4939
>
> David W. Forslund dw...@la...
> Computer and Computational
> Sciences http://www.acl.lanl.gov/~dwf
> Los Alamos National Laboratory Los Alamos, NM
> 87545
> 505-665-1907 FAX: 505-665-4939
|
|
From: Melzer, S. <Ste...@Pa...> - 2001-06-02 00:42:41
|
Hello, my name is Steven Melzer and I am new to both ObjectBridge and persistence in general. I have been looking for a persistence solution for our web based database storage. We are an Oracle shop using Weblogic as our application server. I downloaded ObjectBridge and built a very simple example using MySQL on my local machine at home. It worked well. But I have several questions when it comes to integrating it with WebLogic: 1) It seems that the ConnectionManager holds its own pool of connections. I wish to use WebLogic's DataSource as a connection pool. I can see how to change the source to do this, but i did not want to modify core code without some feedback. 2) The ConnectionManager is a singleton class holding connections. However, I never see these connection being released anywhere. I check StatementForClass and StatementManager, but I cannot find a connection.close(). If the connection is maintained in the ConnectionManager and never released, then the entire application in WebLogic will share the same connections. If our app has hundreds of simultaneous users, then the single connection is going to be a major bottleneck. This goes back to the first question above. thanks in advance, steve Steven Melzer E-Business Technology 813.351.2215 ste...@pa... |
|
From: David F. <dw...@la...> - 2001-06-01 22:32:37
|
Sascha has arrived at the solution to the problem we posted.
There is a problem in the SqlGenerator with the priority of AND and OR.
In SqlGenerator we need to "wrap" the prior generated statement with
parentheses to make the logic correct:
switch (pc.getType())
{
case (Criteria.OR):
{
statement.append( " OR " +
addAtStart);
statement.append(asSQLStatement(pc,
cld));
statement.append(addAtEnd);
break;
}
case (Criteria.AND):
{
statement.insert(0,"( ");
statement.append( ") ");
statement.append(" AND
"+addAtStart);
statement.append(asSQLStatement(pc,
cld));
statement.append(addAtEnd);
break;
}
And further down:
SelectionCriteria c = (SelectionCriteria) o;
if (statement.length() == 0)
{
statement.append(asSQLClause(c, cld));
}
else
{
statement.insert(0,"(");
statement.append(") ");
statement.append(" AND ");
statement.append(asSQLClause(c, cld));
}
Apparently there are no junit tests for any complex queries, which should
have uncovered this problem.
This is still a problem in the just released 0.5.136 version.
Dave
At 12:11 PM 6/1/2001 -0600, David Forslund wrote:
>We have encountered a problem with Objectbridge and are working on a
>solution, but don't have it yet. We have a query with our search filters
>in which we combine them together. We have something like:
>
>ID = 10 OR ID = 12 AND (STATE = 3)
>
>generated by OJBSearchFilter. However this apparently is equivalent to:
>ID=10 OR (ID = 12 AND STATE = 3)
>
>rather than (ID = 10 OR ID=12) AND (STATE = 3)
>
>It seems that when SqlGenerator checks the isEmbraced flag, it never uses
>it for the top level Criteria.
>
>I'm not sure of the proper fix at this point.
>
>David W. Forslund dw...@la...
>Computer and Computational Sciences http://www.acl.lanl.gov/~dwf
>Los Alamos National Laboratory Los Alamos, NM 87545
>505-665-1907 FAX: 505-665-4939
David W. Forslund dw...@la...
Computer and Computational Sciences http://www.acl.lanl.gov/~dwf
Los Alamos National Laboratory Los Alamos, NM 87545
505-665-1907 FAX: 505-665-4939
|
|
From: Thomas M. <tho...@ho...> - 2001-06-01 20:38:31
|
Hi all, The ODMG API is now fully implemented, we are LGPL'ed and thus stepping to the long awaited 0.5 release. >From the release notes: Release 0.5.136 changes in this release: New features: - OQL parameter binding operation implemented - OQL filter operations in ODMG Collection implemented - wrote a tutorial and a code example covering Conversion Strategies - DListImpl, DBagImpl, DSetImpl, DMapImpl and the respective Iterators now provide remove() methods changes, refactorings: - removed the prefix __ from the OJB internal tables, to allow easier ports to Oracle, DB2 and other DBMS - to minimize the size of serialized Identities they are now GZIPed - rewrote the RsIterator methods next() and hasNext() to work even with buggy JDBC 2.0 drivers... - Creation and preparation of prepared Statements now compliant with JDBC 2.0 drivers for DB2 and Oracle. - renamed the package ojb.server to ojb.odmg to better reflect its content. bug fixes: - changed the deletion sequence for dependend objects to prevent referential integrity violations Open bugs: - Testmethods in test.ojb.odmg.OdmgExamples still report failures. in my development environment (VisualAge) I can't reproduce them... This bug is still open but I have some more information now: this bug can only be reproduced with the SUN JVM not with the IBM JVM, so I will debug the stuff under the SUN JVM... With the SUN JDK 1.3.03 this error does also not occur... Best regards, Thomas Mahler |
|
From: David F. <dw...@la...> - 2001-06-01 18:11:16
|
We have encountered a problem with Objectbridge and are working on a solution, but don't have it yet. We have a query with our search filters in which we combine them together. We have something like: ID = 10 OR ID = 12 AND (STATE = 3) generated by OJBSearchFilter. However this apparently is equivalent to: ID=10 OR (ID = 12 AND STATE = 3) rather than (ID = 10 OR ID=12) AND (STATE = 3) It seems that when SqlGenerator checks the isEmbraced flag, it never uses it for the top level Criteria. I'm not sure of the proper fix at this point. David W. Forslund dw...@la... Computer and Computational Sciences http://www.acl.lanl.gov/~dwf Los Alamos National Laboratory Los Alamos, NM 87545 505-665-1907 FAX: 505-665-4939 |
|
From: Mahler T. <tho...@it...> - 2001-05-31 12:07:31
|
Hi Sasha, > -----Urspr=FCngliche Nachricht----- > Von: Sasha Haghani [mailto:sha...@br...] > Gesendet: Dienstag, 29. Mai 2001 22:39 > An: 'obj...@li...' > Betreff: [Objectbridge-developers] Thread-Safety of OJB Classes >=20 >=20 > Hi Thomas and friends, >=20 > I have some questions regarding the thread-safety of some of=20 > the OJB classes > as I will be using them in a multi-threaded application. >=20 > Here is the thread-safety of the key objects, as I understand=20 > them. Please > correct me if I'm wrong. >=20 > ojb.server.OJB: Thread-safe - a single instance can be used=20 > by multiple > threads to instantiate databases. >=20 OK > org.odmg.Database (ojb.server.DatabaseImpl): Not thread-safe?=20 > - one instance > per thread. Are there any issues/limitations with creating a=20 > pool of open > databases? >=20 Everything in the ODMG package should be thread safe. The transaction manager was build to handle transactions running concurrently within separate threads. > Also, from what I can determine from the source code, OJB=20 > maintains one > connection per JdbcConnectionDescriptor in the repository XML=20 > file. Is that > correct? Exactly. regards, Thomas > Thanks, >=20 > Sasha Haghani > Toronto, Canada >=20 > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > http://lists.sourceforge.net/lists/listinfo/objectbridge-developers >=20 |
|
From: Mahler T. <tho...@it...> - 2001-05-31 12:03:59
|
Hi Sasha,
> -----Urspr=FCngliche Nachricht-----
> Von: Sasha Haghani [mailto:sha...@br...]
> Gesendet: Dienstag, 29. Mai 2001 21:27
> An: 'Mahler Thomas'; 'obj...@li...'
> Betreff: RE: [Objectbridge-developers] OJB Dependent=20
> Collections Update
> Be haviour
>=20
>=20
> Hi Thomas (and friends),
>=20
> Thanks for the prompt response to my questions, but I've=20
> still got a few
> unresolved questions, so here they are...
>=20
> 1. Just for the sake of clarity, how would ODMG handle the use case I
> described in my last message?, namely:
>=20
> -> Call database.store() on A (ID:5) with collection of=20
> dependent B objects
> (IDs: 6, 7, 8, 9, 10)
> -> Subsequent database.store() call on A (ID:5) with Bs (IDs:=20
> 8, 9, 10, 11,
> 12).
>=20
The ODMG implementation sets the flags auto.update, auto.delete to =
false.
Thus a store on A does NOT automatically store the B objects!
BUT: if you add a B object to an ODMG collection A, it is automatically
registered to the current transaction. The transaction tracks all =
changes of
objects (newly created objects made persistent, modification of "old"
objects, deletion of "old" objects). On commit it will thus save all B
objects added to the collection.
To get an impression of this mechanism have a look at the method
ojb.server.collections.add(Object)
public void add(int index, Object element)
{
TransactionImpl tx =3D (TransactionImpl)
OJB.getInstance().currentTransaction();
tx.register(this);
this.size++;
DListEntry entry =3D new DListEntry(this, element);
elements.add(index, entry);
// changing the position markers of entries:
int offset =3D 0;
try
{
offset =3D ((DListEntry) elements.get(index -
1)).getPosition();
}
catch (Exception ignored) {}
for (int i =3D offset; i < elements.size(); i++)
{
entry =3D (DListEntry) elements.get(i);
entry.setPosition(i);
}
}
> 2. In your last message, you said the following regarding=20
> recursive handling
> of dependent objects by ODMG (Question #3):
>=20
> ---- Thomas Mahler wrote:
> > As mentioned above the registration of objects to transactions is
> recursive.
> > The store operations are not recursive (i.e. the=20
> auto.update, auto.delete
> > flags are set to false). But as everything is registered=20
> recursively the
> > ODMG implementation can still update all dependent objects.
> ----
>=20
> I didn't understand this. Were you referring to the=20
> PersistenceBroker or
> the ODMG interface when you said "The store operations are=20
> not recursive"?
> Does this mean that when I have object A depending on Bs=20
> which depend on Cs,
> calling the ODMG Database's makePersistent(A) method won't properly
> insert/update the entire object graph? Or did I misunderstand you?
>=20
OK I have make my point clearer. The ODMG implementation uses the
PersistenBroker.store() method. Thus it depends on you setting in the =
XML
repository whether you have cascading updates/deletes or not.
To avoid unnessary updates for dependent objects that have not been
modified, you can set auto.update, auto.delete to false. Then the
Transaction commit stores a A without the dependend B's and only those =
B's
that have been detected.=20
> 3. By Persistent Collections I'm assuming you were refering to the
> ojb.server.collections package which contains the ODMG collection
> implementations. I had a look at all the classes but none of them
> implement/override any remove() methods so I don't see how=20
> the collections
> use the transaction manager to mark entries as deleted. The=20
> persistent
> collections extend various Abstract Java collections in java.util
> (AbstractList, AbstractMap, etc.), but don't seem to override=20
> the remove
> methods. Do the inherited remove() methods still work=20
> correctly in the
> subclasses?
>=20
You are absolutely right, remove() has not yet been implemented. So if =
you
use the ODMG collections with your A B example your B entries won't get
deleted right now!
> You mentioned that this wasn't fully implemented yet -- what=20
> is the current
> fuctionality and limitations of these collections? When do you think
> they'll be completed?
I meant exactly the above mentioned remove() methods. It's not =
difficult to
implemnt those methods, so I can include them in the next release (say =
in 1
or 2 weeks)
>=20
> Does this also mean that in order to make use of ODMG's=20
> dependent object
> tracking facility (using the stateful transaction manager) that our
> persistent objects *must* use the persistent ODMG collections=20
> for dependent
> objects/relationships? Or can we still use regular Java collections?
>=20
The ODMG specification requires an ODMG Vendor to implement certain
persistent collection Interfaces (DList, DBag, DSet ...).=20
But of course you can use arbitrary collections as provided by the OJB
PersistenceBroker.
BUT you are responsible for registering newly added objects and to mark
removed Objects as deleted.
This can be done by reimplemnting stuff from the ODMG collections in =
your
own collections.
> 4. Now that I understand the architecture of OJB, I see what=20
> functionality
> each is meant to provide. Will JDO be built on top of ODMG,=20
> or directly on
> top of the Broker?=20
I think the best thing to do would be to build a OTM (ObjectTransaction
Manager) on Top of the broker and then only have very thin layers for =
the
ODMG and the JDO implementation.
This would of course require a complete refactoring of the ODMG =
package...
I think that the next tutorial (#3)=20
> should definately
> address the handling of relationships and dependent objects. =20
> That is the
> bulk of the functionality and complexity which a tool like=20
> OJB addresses
> (along with inheritence and polymorphism).
>=20
Agreed!
(SO much work so little time)
Thomas
> Thanks again.
>=20
> Sasha Haghani,
> Toronto, Canada.
>=20
> -----Original Message-----
> From: Mahler Thomas [mailto:tho...@it...]
> Sent: Tuesday, May 29, 2001 3:26 AM
> To: 'Sasha Haghani'; 'obj...@li...'
> Subject: AW: [Objectbridge-developers] OJB Dependent=20
> Collections Update
> Be haviour
>=20
>=20
> Hi Sasha, hi all,
>=20
> > -----Urspr=FCngliche Nachricht-----
> > Von: Sasha Haghani [mailto:sha...@br...]
> > Gesendet: Dienstag, 29. Mai 2001 02:00
> > An: 'obj...@li...'
> > Betreff: [Objectbridge-developers] OJB Dependent Collections Update
> > Behaviour
> >=20
> >=20
> > Hi Thomas,
> >=20
> > In your last message on the subject of how OJB updates=20
> collections of
> > dependent objects, you said:
> >=20
> > -----
> > Inserting newly added objects in a Collection attribute
> > DOES work!
> >=20
> > If you call PersistenceBroker.store(), the=20
> PersistenceBroker does NOT
> > know that you have deleted items from a collection! It does=20
> > only see the
> > actual items in the collection! If you use the=20
> > PersistenceBroker API you
> > have to implement your own tracking mechanism that detects obsolete
> > objects and call .delete(obj) on you own. (You could add such=20
> > a thing in
> > your collections .remove(obj) method).
> >=20
> > The ODMG implementation provides an object transaction=20
> > manager that does
> > contain such a tracking.
> > -----
> >=20
> > I have a number of questions about this, so I'll list them=20
> > one at a time...
> >=20
> > 1. Can you describe how the following case would be handled:
> > -> Call broker.store() on A (ID:5) with collection of=20
> > dependent B objects
> > (IDs: 6, 7, 8, 9, 10)
> > -> Subsequent broker.store() call on A (ID:5) with Bs (IDs:=20
> > 8, 9, 10, 11,
> > 12).
> >=20
> > As I understand it, in the database we would end up with A=20
> > related to 7 Bs
> > (IDs: 6 through 12), with Bs 8 through 10 updated on the=20
> > second call to
> > store(). Is this correct?
> >=20
>=20
> Yes, exactly. Of course this result is at least misleading=20
> (if not an error)
> as your intention is to have items 6 and 7 deleted from the DB!
>=20
> > 2. Why is it that the ODMG provides this collection tracking=20
> > facility but
> > the Broker does not? Isn't the ODMG interface built on top=20
> > of the Broker?
> > How would ODMG handle the above case?
> >=20
>=20
> The Broker is designed to be stateless service. If you ask to store =
an
> object it just does so but it has no means to check previous=20
> state of your
> object.
> The Broker has been designed as a service providing db access for =
more
> complete stateful and transactional persistence manager like the ODMG
> implementation or the (planed) JDO implementation.
> The ODMG implementation USES the Broker but is not limited to=20
> the brokers
> features.
> This is a typical layered architechture.
>=20
> The ODMG implementation has a transaction manager that=20
> explicitely registers
> objects to transactions. Objects are registered recursively=20
> with all there
> dependent objects getting also registered. On registration a=20
> clone of each
> object is generated that contains the initial state of the=20
> object. On a
> transaction rollback the initial state of all objects is=20
> reconstructed. On
> commit The TransactionManager checks the ModificationState of each
> registered object. If an already persistent object has been=20
> modified it asks
> the PersistenceBroker to perform an UPDATE (by using an=20
> ObjectModification).
> If an Object is marked for deletion, the Broker is asked to=20
> perfom a DELETE,
> etc. (see the classes in package ojb.server.states, applying a "cool"
> combination of state- and command pattern).
>=20
> > 3. Does ODMG recursively update/handle dependent objects=20
> > (i.e.: A depends on
> > B which depends on C)?
> >=20
>=20
> As mentioned above the registration of objects to=20
> transactions is recursive.
> The store operations are not recursive (i.e. the auto.update,=20
> auto.delete
> flags are set to false). But as everything is registered=20
> recursively the
> ODMG implementation can still update all dependent objects. The big
> difference: ODMG does only update if necessary, the Broker does =
always
> update even if no modifications occured in dependent objects.
>=20
> > 4. How does ODMG know/determine which dependent=20
> > references/collections to
> > update/delete if ODMG ignores the auto.delete and auto.update=20
> > settings (as
> > you had said in an earlier message)?
> >=20
>=20
> The persistent collection classes are responsible to register=20
> new added
> elements to the current transaction and to mark=20
> element-entries (not the
> element objects themselves !) for deletion if they are=20
> removed from the
> collection. (This is not yet implemented completely, but you=20
> may get an idea
> of the interaction of colletcions with the TransactionManager=20
> by having a
> look at the class ojb.server.collections.DListImpl)
>=20
>=20
>=20
> > 5. Is it possible, safe and recommended to mix-and-match the=20
> > use of the
> > Broker interface for delete operations (since it handles=20
> > cascaded deletes of
> > dependent objects) and ODMG for update and insert=20
> operations (since it
> > handles updates on collections of dependent objects)? Is it=20
> > wise to event
> > attempt this approach? Can you forsee any potential problems?
> >
>=20
> No, don't do this! The PersistenceBroker does not track object
> modifications, has no object transactions, no lock management=20
> etc. So you
> would really get trouble using a mixed approach.
> The is one exception from this rule: It is safe to use the
> PersistenceBrokers query facilities to lookup objects.=20
>=20
> =20
> > 6. Finally, I may be interested in implementing this=20
> > collection tracking
> > facility for the Broker, depending on how complex and=20
> > time-consuming such an
> > undertaking would be. Could you describe requirements (i.e.:=20
> > bullet points)
> > of how and where (in the source code) such an improvement=20
> > would be made,
> > including how other features such as Transactions, Object Cache,
> > Descriptors, Recursive Dependencies, would be affected. =20
> > Would it possible
> > to port the ODMG functionality into the Broker?
>=20
> Of course it's possible to implement this (as the ODMG implementation
> shows).
> You basically have to re-write everything of the ODMG=20
> implementation apart
> from OQL and named roots:
> - a TransactionManager that provides objectlevel transactions
> - a StateHandler that handles transaction commit and rollback
> - a LockManager handling concurrent object requests of transactions
>=20
> The JDO implementation will also reuse a lot of code from the odmg
> implementation.
> So it may be a valid approach to factor out these "Object=20
> TransactionManager
> (OTM)" to avoid "copy and paste"-reuse.
>=20
> But personally I think it's not a good idea to incorparate=20
> hese features
> into the Broker, because the Broker services are on a lower=20
> level than the
> OTM services. (The Broker must know about JDBC and the O/R=20
> mapping. The OTM
> must know nothing about JDBC but needs a service to perform =
store(obj)
> operations. Thus I would always recomend a layered approach.)
>=20
> thanks for your stimulating questions!
>=20
> Thomas Mahler=20
> Essen, Germany
>=20
>=20
> >=20
> > That's it for now. Thanks again.
> >=20
> > Sasha Haghani
> > Toronto, Canada.
> >=20
> >=20
> > _______________________________________________
> > Objectbridge-developers mailing list
> > Obj...@li...
> > http://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> >=20
>=20
|
|
From: Mahler T. <tho...@it...> - 2001-05-31 07:49:44
|
Hi all, > -----Urspr=FCngliche Nachricht----- > Von: Christian Sell [mailto:chr...@ne...] > Gesendet: Mittwoch, 30. Mai 2001 00:22 > An: obj...@li... > Betreff: Re: [Objectbridge-developers] Sample Many-to-Many Mapping = XML >=20 >=20 > Hi Thomas and all, >=20 > as this touches one of my pet subjects ;-), I have to raise=20 > my voice here: >=20 > >Right now this is exactly the thing you have to do! You need=20 > three tables > to > >decompose m-n into two 1-n relationships. Thus you also need=20 > three classes. > >This approach is also suggested by the gurus: see > >ftp://members.aol.com/kgb1001001/Chasms/chasms.pdf. >=20 > Now what exactly makes someone a "guru"? Writing an article=20 > like that one? I > think figuring out that you have to introduce an intermediary=20 > entity for an > N-M relationship (unless your O/R tool handles them=20 > transparently) does not > require deep understanding - its simply the only way to get=20 > there, as it > directly reflects the table structure. I did not want to say that using 3 classes direcly reflecting the table structure is "the holy gral" of O/R mapping. I just mentioned the = crossing chasms pattern language as it presents a widely accepted approach. Rock solid commercial products like TopLink are based on their = insights. There are even OO databases like Objectivity that use Relationship = classes for modelling m-n relationships. Of course OJB aims to incorporate everything a OO designer/developer = needs to build well designed applications.=20 It would be cool to have the m-n mechanisms completely hidden in the persistence layer! Say we have classes User and Role with an M-N relationship as given by Sasha's example. It will be relatively easy to hide the functionality of the UserRoleRelationship class in the OJB framework. Now imagine we have an attributed Relationship (UML allows to model = such things!) between User and Role. The Relationship has an attribute = boolean isDefault, that is true for a users default role and false for all = other roles. You will have to place this attribute into the USER_ROLE table as it is = an individual attribute of each relationship. I don't see how such attributed relationships could be cleanly modelled without a UserRoleRelationship class. Do you have any ideas how OJB could automatically handle such a = situation?=20 cheers, Thomas >=20 > just my 2c, as always > Christian >=20 >=20 > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > http://lists.sourceforge.net/lists/listinfo/objectbridge-developers >=20 |
|
From: Christian S. <chr...@ne...> - 2001-05-29 22:22:42
|
Hi Thomas and all, as this touches one of my pet subjects ;-), I have to raise my voice here: >Right now this is exactly the thing you have to do! You need three tables to >decompose m-n into two 1-n relationships. Thus you also need three classes. >This approach is also suggested by the gurus: see >ftp://members.aol.com/kgb1001001/Chasms/chasms.pdf. Now what exactly makes someone a "guru"? Writing an article like that one? I think figuring out that you have to introduce an intermediary entity for an N-M relationship (unless your O/R tool handles them transparently) does not require deep understanding - its simply the only way to get there, as it directly reflects the table structure. just my 2c, as always Christian |
|
From: Sasha H. <sha...@br...> - 2001-05-29 20:38:52
|
Hi Thomas and friends, I have some questions regarding the thread-safety of some of the OJB classes as I will be using them in a multi-threaded application. Here is the thread-safety of the key objects, as I understand them. Please correct me if I'm wrong. ojb.server.OJB: Thread-safe - a single instance can be used by multiple threads to instantiate databases. org.odmg.Database (ojb.server.DatabaseImpl): Not thread-safe? - one instance per thread. Are there any issues/limitations with creating a pool of open databases? Also, from what I can determine from the source code, OJB maintains one connection per JdbcConnectionDescriptor in the repository XML file. Is that correct? Thanks, Sasha Haghani Toronto, Canada |
|
From: Sasha H. <sha...@br...> - 2001-05-29 19:27:00
|
Hi Thomas (and friends), Thanks for the prompt response to my questions, but I've still got a = few unresolved questions, so here they are... 1. Just for the sake of clarity, how would ODMG handle the use case I described in my last message?, namely: -> Call database.store() on A (ID:5) with collection of dependent B = objects (IDs: 6, 7, 8, 9, 10) -> Subsequent database.store() call on A (ID:5) with Bs (IDs: 8, 9, 10, = 11, 12). 2. In your last message, you said the following regarding recursive = handling of dependent objects by ODMG (Question #3): ---- Thomas Mahler wrote: > As mentioned above the registration of objects to transactions is recursive. > The store operations are not recursive (i.e. the auto.update, = auto.delete > flags are set to false). But as everything is registered recursively = the > ODMG implementation can still update all dependent objects. ---- I didn't understand this. Were you referring to the PersistenceBroker = or the ODMG interface when you said "The store operations are not = recursive"? Does this mean that when I have object A depending on Bs which depend = on Cs, calling the ODMG Database's makePersistent(A) method won't properly insert/update the entire object graph? Or did I misunderstand you? 3. By Persistent Collections I'm assuming you were refering to the ojb.server.collections package which contains the ODMG collection implementations. I had a look at all the classes but none of them implement/override any remove() methods so I don't see how the = collections use the transaction manager to mark entries as deleted. The persistent collections extend various Abstract Java collections in java.util (AbstractList, AbstractMap, etc.), but don't seem to override the = remove methods. Do the inherited remove() methods still work correctly in the subclasses? You mentioned that this wasn't fully implemented yet -- what is the = current fuctionality and limitations of these collections? When do you think they'll be completed? Does this also mean that in order to make use of ODMG's dependent = object tracking facility (using the stateful transaction manager) that our persistent objects *must* use the persistent ODMG collections for = dependent objects/relationships? Or can we still use regular Java collections? 4. Now that I understand the architecture of OJB, I see what = functionality each is meant to provide. Will JDO be built on top of ODMG, or = directly on top of the Broker? I think that the next tutorial (#3) should = definately address the handling of relationships and dependent objects. That is = the bulk of the functionality and complexity which a tool like OJB = addresses (along with inheritence and polymorphism). Thanks again. Sasha Haghani, Toronto, Canada. -----Original Message----- From: Mahler Thomas [mailto:tho...@it...] Sent: Tuesday, May 29, 2001 3:26 AM To: 'Sasha Haghani'; 'obj...@li...' Subject: AW: [Objectbridge-developers] OJB Dependent Collections Update Be haviour Hi Sasha, hi all, > -----Urspr=FCngliche Nachricht----- > Von: Sasha Haghani [mailto:sha...@br...] > Gesendet: Dienstag, 29. Mai 2001 02:00 > An: 'obj...@li...' > Betreff: [Objectbridge-developers] OJB Dependent Collections Update > Behaviour >=20 >=20 > Hi Thomas, >=20 > In your last message on the subject of how OJB updates collections of > dependent objects, you said: >=20 > ----- > Inserting newly added objects in a Collection attribute > DOES work! >=20 > If you call PersistenceBroker.store(), the PersistenceBroker does NOT > know that you have deleted items from a collection! It does=20 > only see the > actual items in the collection! If you use the=20 > PersistenceBroker API you > have to implement your own tracking mechanism that detects obsolete > objects and call .delete(obj) on you own. (You could add such=20 > a thing in > your collections .remove(obj) method). >=20 > The ODMG implementation provides an object transaction=20 > manager that does > contain such a tracking. > ----- >=20 > I have a number of questions about this, so I'll list them=20 > one at a time... >=20 > 1. Can you describe how the following case would be handled: > -> Call broker.store() on A (ID:5) with collection of=20 > dependent B objects > (IDs: 6, 7, 8, 9, 10) > -> Subsequent broker.store() call on A (ID:5) with Bs (IDs:=20 > 8, 9, 10, 11, > 12). >=20 > As I understand it, in the database we would end up with A=20 > related to 7 Bs > (IDs: 6 through 12), with Bs 8 through 10 updated on the=20 > second call to > store(). Is this correct? >=20 Yes, exactly. Of course this result is at least misleading (if not an = error) as your intention is to have items 6 and 7 deleted from the DB! > 2. Why is it that the ODMG provides this collection tracking=20 > facility but > the Broker does not? Isn't the ODMG interface built on top=20 > of the Broker? > How would ODMG handle the above case? >=20 The Broker is designed to be stateless service. If you ask to store an object it just does so but it has no means to check previous state of = your object. The Broker has been designed as a service providing db access for more complete stateful and transactional persistence manager like the ODMG implementation or the (planed) JDO implementation. The ODMG implementation USES the Broker but is not limited to the = brokers features. This is a typical layered architechture. The ODMG implementation has a transaction manager that explicitely = registers objects to transactions. Objects are registered recursively with all = there dependent objects getting also registered. On registration a clone of = each object is generated that contains the initial state of the object. On a transaction rollback the initial state of all objects is reconstructed. = On commit The TransactionManager checks the ModificationState of each registered object. If an already persistent object has been modified it = asks the PersistenceBroker to perform an UPDATE (by using an = ObjectModification). If an Object is marked for deletion, the Broker is asked to perfom a = DELETE, etc. (see the classes in package ojb.server.states, applying a "cool" combination of state- and command pattern). > 3. Does ODMG recursively update/handle dependent objects=20 > (i.e.: A depends on > B which depends on C)? >=20 As mentioned above the registration of objects to transactions is = recursive. The store operations are not recursive (i.e. the auto.update, = auto.delete flags are set to false). But as everything is registered recursively = the ODMG implementation can still update all dependent objects. The big difference: ODMG does only update if necessary, the Broker does always update even if no modifications occured in dependent objects. > 4. How does ODMG know/determine which dependent=20 > references/collections to > update/delete if ODMG ignores the auto.delete and auto.update=20 > settings (as > you had said in an earlier message)? >=20 The persistent collection classes are responsible to register new added elements to the current transaction and to mark element-entries (not = the element objects themselves !) for deletion if they are removed from the collection. (This is not yet implemented completely, but you may get an = idea of the interaction of colletcions with the TransactionManager by having = a look at the class ojb.server.collections.DListImpl) > 5. Is it possible, safe and recommended to mix-and-match the=20 > use of the > Broker interface for delete operations (since it handles=20 > cascaded deletes of > dependent objects) and ODMG for update and insert operations (since = it > handles updates on collections of dependent objects)? Is it=20 > wise to event > attempt this approach? Can you forsee any potential problems? > No, don't do this! The PersistenceBroker does not track object modifications, has no object transactions, no lock management etc. So = you would really get trouble using a mixed approach. The is one exception from this rule: It is safe to use the PersistenceBrokers query facilities to lookup objects.=20 =20 > 6. Finally, I may be interested in implementing this=20 > collection tracking > facility for the Broker, depending on how complex and=20 > time-consuming such an > undertaking would be. Could you describe requirements (i.e.:=20 > bullet points) > of how and where (in the source code) such an improvement=20 > would be made, > including how other features such as Transactions, Object Cache, > Descriptors, Recursive Dependencies, would be affected. =20 > Would it possible > to port the ODMG functionality into the Broker? Of course it's possible to implement this (as the ODMG implementation shows). You basically have to re-write everything of the ODMG implementation = apart from OQL and named roots: - a TransactionManager that provides objectlevel transactions - a StateHandler that handles transaction commit and rollback - a LockManager handling concurrent object requests of transactions The JDO implementation will also reuse a lot of code from the odmg implementation. So it may be a valid approach to factor out these "Object = TransactionManager (OTM)" to avoid "copy and paste"-reuse. But personally I think it's not a good idea to incorparate hese = features into the Broker, because the Broker services are on a lower level than = the OTM services. (The Broker must know about JDBC and the O/R mapping. The = OTM must know nothing about JDBC but needs a service to perform store(obj) operations. Thus I would always recomend a layered approach.) thanks for your stimulating questions! Thomas Mahler=20 Essen, Germany >=20 > That's it for now. Thanks again. >=20 > Sasha Haghani > Toronto, Canada. >=20 >=20 > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > http://lists.sourceforge.net/lists/listinfo/objectbridge-developers >=20 |
|
From: Mahler T. <tho...@it...> - 2001-05-29 08:07:04
|
Hi Sasha, hi all, > -----Urspr=FCngliche Nachricht----- > Von: Sasha Haghani [mailto:sha...@br...] > Gesendet: Dienstag, 29. Mai 2001 01:21 > An: 'obj...@li...' > Betreff: [Objectbridge-developers] Sample Many-to-Many Mapping XML >=20 >=20 > Hi Thomas et al, >=20 > I have a question about how to implement a M-M relationship=20 > using OJB. I've > included a sample mapping which uses three objects, User, Role & > UserRoleRelationship. User and Role each have a collection of > UserRoleRelationship objects. And UserRoleRelationship has a=20 > single ID and > reference field for both User and Role respectively. >=20 > Can someone verify that this mapping is correct. Is there anyway to > simplify it further? Is a UserRoleRelationship object=20 > absolutely necessary? Right now this is exactly the thing you have to do! You need three = tables to decompose m-n into two 1-n relationships. Thus you also need three = classes. This approach is also suggested by the gurus: see ftp://members.aol.com/kgb1001001/Chasms/chasms.pdf. As there have been requests to have a standard mapping for m-n = relationships I'm thinking of having some support for m-n in OJB at some later point = in time ... > Note that I've defined both the userid and roleid columns as=20 > primary keys > for the UserRoleRelationship (user_role table) -- is that valid? >=20 Of course the combination of userid and roleid must be unique. If you = use them as PK you don't even need a separate ID column. > Finally, are my auto.* settings configured correctly? I'd=20 > like the deletion > of a User or Role to delete the object and any corresponding > UserRoleRelationships, both *NOT* the other side of the=20 > relation (i.e.: > typical Many-to-Many behaviour). Retrieving any object=20 > should retrieve any > dependent object (User gets related UserRoleRelationships and=20 > Roles, etc.). >=20 > Any help on this or any alternative mapping samples are much=20 > appreciated. > Thanks. The mapping sample XML is below... >=20 > Sasha Haghani > Toronto, Canada. >=20 > <ClassDescriptor id=3D"1"> > <class.name>User</class.name> > <table.name>user</table.name> > <FieldDescriptor id=3D"1"> > <field.name>userid</field.name> > <column.name>userid</column.name> > <jdbc_type>CHAR</jdbc_type> > <PrimaryKey>true</PrimaryKey> > </FieldDescriptor> > <FieldDescriptor id=3D"2"> > <field.name>username</field.name> > <column.name>username</column.name> > <jdbc_type>CHAR</jdbc_type> > </FieldDescriptor> > <CollectionDescriptor id=3D"1"> > <cdfield.name>roles</cdfield.name> > <items.class>UserRoleRelationship</items.class> > <descriptor_ids>1</descriptor_ids> > <auto.retrieve>true</auto.retrieve> > <auto.update>true</auto.update> > <auto.delete>true</auto.delete> > </CollectionDescriptor> > </ClassDescriptor> >=20 > <ClassDescriptor id=3D"2"> > <class.name>UserRoleRelationship</class.name> > <table.name>user_role</table.name> > <FieldDescriptor id=3D"1"> > <field.name>userid</field.name> > <column.name>userid</column.name> > <jdbc_type>CHAR</jdbc_type> > <PrimaryKey>true</PrimaryKey> > </FieldDescriptor> > <FieldDescriptor id=3D"2"> > <field.name>roleid</field.name> > <column.name>roleid</column.name> > <jdbc_type>CHAR</jdbc_type> > <PrimaryKey>true</PrimaryKey> > </FieldDescriptor> > <ReferenceDescriptor id=3D"1"> > <rdfield.name>user</rdfield.name> > <referenced.class>User</referenced.class> > <descriptor_ids>1</descriptor_ids> > <auto.retrieve>true</auto.retrieve> > <auto.update>false</auto.update> > <auto.delete>false</auto.delete> > </ReferenceDescriptor> > <ReferenceDescriptor id=3D"2"> > <rdfield.name>role</rdfield.name> > <referenced.class>Role</referenced.class> > <descriptor_ids>2</descriptor_ids> > <auto.retrieve>true</auto.retrieve> > <auto.update>false</auto.update> > <auto.delete>false</auto.delete> > </ReferenceDescriptor> > </ClassDescriptor> >=20 > <ClassDescriptor id=3D"3"> > <class.name>Role</class.name> > <table.name>role</table.name> > <FieldDescriptor id=3D"1"> > <field.name>roleid</field.name> > <column.name>roleid</column.name> > <jdbc_type>CHAR</jdbc_type> > <PrimaryKey>true</PrimaryKey> > </FieldDescriptor> > <FieldDescriptor id=3D"2"> > <field.name>rolename</field.name> > <column.name>rolename</column.name> > <jdbc_type>CHAR</jdbc_type> > </FieldDescriptor> > <CollectionDescriptor id=3D"1"> > <cdfield.name>roles</cdfield.name> > <items.class>UserRoleRelationship</items.class> > <descriptor_ids>2</descriptor_ids> > <auto.retrieve>true</auto.retrieve> > <auto.update>true</auto.update> > <auto.delete>true</auto.delete> > </CollectionDescriptor> > </ClassDescriptor>=09 >=20 Yes this looks good! If a user is deleted all dependent = UserRoleRelationship entries are deleted, but role entries are not touched, as the = auto.update and auto.delete flags are set to false! Sasha, I have a question: could you send me the sources for classes = User, Role and UserRoleRelationship? Until now I have no sample for a m-n mapping and would like to include something simple into our test package for demonstration of mapping techniques. thanks, Thomas > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > http://lists.sourceforge.net/lists/listinfo/objectbridge-developers >=20 |
|
From: Mahler T. <tho...@it...> - 2001-05-29 07:26:30
|
Hi Sasha, hi all, > -----Urspr=FCngliche Nachricht----- > Von: Sasha Haghani [mailto:sha...@br...] > Gesendet: Dienstag, 29. Mai 2001 02:00 > An: 'obj...@li...' > Betreff: [Objectbridge-developers] OJB Dependent Collections Update > Behaviour >=20 >=20 > Hi Thomas, >=20 > In your last message on the subject of how OJB updates collections of > dependent objects, you said: >=20 > ----- > Inserting newly added objects in a Collection attribute > DOES work! >=20 > If you call PersistenceBroker.store(), the PersistenceBroker does NOT > know that you have deleted items from a collection! It does=20 > only see the > actual items in the collection! If you use the=20 > PersistenceBroker API you > have to implement your own tracking mechanism that detects obsolete > objects and call .delete(obj) on you own. (You could add such=20 > a thing in > your collections .remove(obj) method). >=20 > The ODMG implementation provides an object transaction=20 > manager that does > contain such a tracking. > ----- >=20 > I have a number of questions about this, so I'll list them=20 > one at a time... >=20 > 1. Can you describe how the following case would be handled: > -> Call broker.store() on A (ID:5) with collection of=20 > dependent B objects > (IDs: 6, 7, 8, 9, 10) > -> Subsequent broker.store() call on A (ID:5) with Bs (IDs:=20 > 8, 9, 10, 11, > 12). >=20 > As I understand it, in the database we would end up with A=20 > related to 7 Bs > (IDs: 6 through 12), with Bs 8 through 10 updated on the=20 > second call to > store(). Is this correct? >=20 Yes, exactly. Of course this result is at least misleading (if not an = error) as your intention is to have items 6 and 7 deleted from the DB! > 2. Why is it that the ODMG provides this collection tracking=20 > facility but > the Broker does not? Isn't the ODMG interface built on top=20 > of the Broker? > How would ODMG handle the above case? >=20 The Broker is designed to be stateless service. If you ask to store an object it just does so but it has no means to check previous state of = your object. The Broker has been designed as a service providing db access for more complete stateful and transactional persistence manager like the ODMG implementation or the (planed) JDO implementation. The ODMG implementation USES the Broker but is not limited to the = brokers features. This is a typical layered architechture. The ODMG implementation has a transaction manager that explicitely = registers objects to transactions. Objects are registered recursively with all = there dependent objects getting also registered. On registration a clone of = each object is generated that contains the initial state of the object. On a transaction rollback the initial state of all objects is reconstructed. = On commit The TransactionManager checks the ModificationState of each registered object. If an already persistent object has been modified it = asks the PersistenceBroker to perform an UPDATE (by using an = ObjectModification). If an Object is marked for deletion, the Broker is asked to perfom a = DELETE, etc. (see the classes in package ojb.server.states, applying a "cool" combination of state- and command pattern). > 3. Does ODMG recursively update/handle dependent objects=20 > (i.e.: A depends on > B which depends on C)? >=20 As mentioned above the registration of objects to transactions is = recursive. The store operations are not recursive (i.e. the auto.update, = auto.delete flags are set to false). But as everything is registered recursively = the ODMG implementation can still update all dependent objects. The big difference: ODMG does only update if necessary, the Broker does always update even if no modifications occured in dependent objects. > 4. How does ODMG know/determine which dependent=20 > references/collections to > update/delete if ODMG ignores the auto.delete and auto.update=20 > settings (as > you had said in an earlier message)? >=20 The persistent collection classes are responsible to register new added elements to the current transaction and to mark element-entries (not = the element objects themselves !) for deletion if they are removed from the collection. (This is not yet implemented completely, but you may get an = idea of the interaction of colletcions with the TransactionManager by having = a look at the class ojb.server.collections.DListImpl) > 5. Is it possible, safe and recommended to mix-and-match the=20 > use of the > Broker interface for delete operations (since it handles=20 > cascaded deletes of > dependent objects) and ODMG for update and insert operations (since = it > handles updates on collections of dependent objects)? Is it=20 > wise to event > attempt this approach? Can you forsee any potential problems? > No, don't do this! The PersistenceBroker does not track object modifications, has no object transactions, no lock management etc. So = you would really get trouble using a mixed approach. The is one exception from this rule: It is safe to use the PersistenceBrokers query facilities to lookup objects.=20 =20 > 6. Finally, I may be interested in implementing this=20 > collection tracking > facility for the Broker, depending on how complex and=20 > time-consuming such an > undertaking would be. Could you describe requirements (i.e.:=20 > bullet points) > of how and where (in the source code) such an improvement=20 > would be made, > including how other features such as Transactions, Object Cache, > Descriptors, Recursive Dependencies, would be affected. =20 > Would it possible > to port the ODMG functionality into the Broker? Of course it's possible to implement this (as the ODMG implementation shows). You basically have to re-write everything of the ODMG implementation = apart from OQL and named roots: - a TransactionManager that provides objectlevel transactions - a StateHandler that handles transaction commit and rollback - a LockManager handling concurrent object requests of transactions The JDO implementation will also reuse a lot of code from the odmg implementation. So it may be a valid approach to factor out these "Object = TransactionManager (OTM)" to avoid "copy and paste"-reuse. But personally I think it's not a good idea to incorparate hese = features into the Broker, because the Broker services are on a lower level than = the OTM services. (The Broker must know about JDBC and the O/R mapping. The = OTM must know nothing about JDBC but needs a service to perform store(obj) operations. Thus I would always recomend a layered approach.) thanks for your stimulating questions! Thomas Mahler=20 Essen, Germany >=20 > That's it for now. Thanks again. >=20 > Sasha Haghani > Toronto, Canada. >=20 >=20 > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > http://lists.sourceforge.net/lists/listinfo/objectbridge-developers >=20 |
9 messages has been excluded from this view by a project administrator.
