objectbridge-developers Mailing List for ObJectRelationalBridge (Page 55)
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: Sasha H. <sha...@br...> - 2001-05-29 00:00:33
|
Hi Thomas, In your last message on the subject of how OJB updates collections of dependent objects, you said: ----- Inserting newly added objects in a Collection attribute DOES work! If you call PersistenceBroker.store(), the PersistenceBroker does NOT know that you have deleted items from a collection! It does only see the actual items in the collection! If you use the 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 a thing in your collections .remove(obj) method). The ODMG implementation provides an object transaction manager that does contain such a tracking. ----- I have a number of questions about this, so I'll list them one at a time... 1. Can you describe how the following case would be handled: -> Call broker.store() on A (ID:5) with collection of dependent B objects (IDs: 6, 7, 8, 9, 10) -> Subsequent broker.store() call on A (ID:5) with Bs (IDs: 8, 9, 10, 11, 12). As I understand it, in the database we would end up with A related to 7 Bs (IDs: 6 through 12), with Bs 8 through 10 updated on the second call to store(). Is this correct? 2. Why is it that the ODMG provides this collection tracking facility but the Broker does not? Isn't the ODMG interface built on top of the Broker? How would ODMG handle the above case? 3. Does ODMG recursively update/handle dependent objects (i.e.: A depends on B which depends on C)? 4. How does ODMG know/determine which dependent references/collections to update/delete if ODMG ignores the auto.delete and auto.update settings (as you had said in an earlier message)? 5. Is it possible, safe and recommended to mix-and-match the use of the Broker interface for delete operations (since it handles cascaded deletes of dependent objects) and ODMG for update and insert operations (since it handles updates on collections of dependent objects)? Is it wise to event attempt this approach? Can you forsee any potential problems? 6. Finally, I may be interested in implementing this collection tracking facility for the Broker, depending on how complex and time-consuming such an undertaking would be. Could you describe requirements (i.e.: bullet points) of how and where (in the source code) such an improvement would be made, including how other features such as Transactions, Object Cache, Descriptors, Recursive Dependencies, would be affected. Would it possible to port the ODMG functionality into the Broker? That's it for now. Thanks again. Sasha Haghani Toronto, Canada. |
|
From: Sasha H. <sha...@br...> - 2001-05-28 23:20:41
|
Hi Thomas et al,
I have a question about how to implement a M-M relationship 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 single ID and
reference field for both User and Role respectively.
Can someone verify that this mapping is correct. Is there anyway to
simplify it further? Is a UserRoleRelationship object absolutely necessary?
Note that I've defined both the userid and roleid columns as primary keys
for the UserRoleRelationship (user_role table) -- is that valid?
Finally, are my auto.* settings configured correctly? I'd like the deletion
of a User or Role to delete the object and any corresponding
UserRoleRelationships, both *NOT* the other side of the relation (i.e.:
typical Many-to-Many behaviour). Retrieving any object should retrieve any
dependent object (User gets related UserRoleRelationships and Roles, etc.).
Any help on this or any alternative mapping samples are much appreciated.
Thanks. The mapping sample XML is below...
Sasha Haghani
Toronto, Canada.
<ClassDescriptor id="1">
<class.name>User</class.name>
<table.name>user</table.name>
<FieldDescriptor id="1">
<field.name>userid</field.name>
<column.name>userid</column.name>
<jdbc_type>CHAR</jdbc_type>
<PrimaryKey>true</PrimaryKey>
</FieldDescriptor>
<FieldDescriptor id="2">
<field.name>username</field.name>
<column.name>username</column.name>
<jdbc_type>CHAR</jdbc_type>
</FieldDescriptor>
<CollectionDescriptor id="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>
<ClassDescriptor id="2">
<class.name>UserRoleRelationship</class.name>
<table.name>user_role</table.name>
<FieldDescriptor id="1">
<field.name>userid</field.name>
<column.name>userid</column.name>
<jdbc_type>CHAR</jdbc_type>
<PrimaryKey>true</PrimaryKey>
</FieldDescriptor>
<FieldDescriptor id="2">
<field.name>roleid</field.name>
<column.name>roleid</column.name>
<jdbc_type>CHAR</jdbc_type>
<PrimaryKey>true</PrimaryKey>
</FieldDescriptor>
<ReferenceDescriptor id="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="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>
<ClassDescriptor id="3">
<class.name>Role</class.name>
<table.name>role</table.name>
<FieldDescriptor id="1">
<field.name>roleid</field.name>
<column.name>roleid</column.name>
<jdbc_type>CHAR</jdbc_type>
<PrimaryKey>true</PrimaryKey>
</FieldDescriptor>
<FieldDescriptor id="2">
<field.name>rolename</field.name>
<column.name>rolename</column.name>
<jdbc_type>CHAR</jdbc_type>
</FieldDescriptor>
<CollectionDescriptor id="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>
|
|
From: Mahler T. <tho...@it...> - 2001-05-23 07:17:02
|
> -----Urspr=FCngliche Nachricht----- > Von: Christian Sell [mailto:chr...@ne...] > Gesendet: Mittwoch, 23. Mai 2001 00:33 > An: obj...@li... > Betreff: [Objectbridge-developers] Re: OJB Technical Questions & > Tutorial #3 >=20 >=20 > Hello, >=20 > Hope you dont mind that I throw in my few cents here: >=20 > > > SUPPORT FOR MAPPING MANY-MANY RELATIONSHIPS > > > Does OJB currently support the mapping of many-to-many > > > relationships? I > > > didn't see any examples in the tests. If not, is this=20 > planned for an > > > upcoming release? > > > > > You are right, there is no support for m-n relationships.=20 > You have to > > decompose it into two 1-n relationships. You have to do=20 > this for your > RDBMS > > ER model anyway, so its not such a big problem in my eyes. > > There are some OJB users (marquier et al.) who are thinking=20 > of building an > > n-m extension. But right now there are no concrete plans to=20 > include such a > > feature. >=20 > I dont think the fact that in physical database modeling you=20 > decompose N-M > relationships into separate 1-N relationships makes this a less = useful > (should I say crucial?) feature fo an O/R modeling tool.=20 > After all, it is > the very purpose of the O/R tool to cover the technical=20 > details with a more > abstract and intuitive layer. And even if I was going to=20 > program plain SQL, > I would use a double join to directly access the final target=20 > entity and not > load the rows of the associative table and then proceed from there. >=20 Sure, covering M-N with an O/R tool is an important feature.=20 The current development on OJB is mostly concerned with basic infrastructure. (Implementing ODMG, building a distributed architecture) Things like - automated generation of proxy classes - automated support for M-N Relationships - automated generation of mapping data and DLL from java classes - automated reengineering of DDL to java classes and mapping data - XMI interface - GUI Mapping Workbench are useful things (that's why commercial tools like toplink have them). = But they only make sense when the basic infrastructure is stable.=20 Of course I have no objections if some volunteers start working on M-N = or the like :-) > > > ASSIGNING IDENTITY VALUES > > > Some of the object graphs that I will be persisting have > > > dependent/related > > > objects which do not have IDs. Do all objects have to=20 > have IDs when > > > persisting using OJB? If so, is there a way to have OJB=20 > transparently > > > assign IDs using the SequenceManager, without the client code > > > needing to > > > call SequenceManager.getUniqueId() for each object? If not, > > > can I use a > > > ConversionStrategy as a means of implementing transparent ID > > > assignment? > > > > I'm not sure if I get you right: Your database table have=20 > no primary key > > columns? Or do they have non numeric keys? Or do you have=20 > compound keys, > > that contain of two or more columns? > > > > OJB does require to have primary keys. But they can be of=20 > arbitrary type > > (not only INT) and may also be compound keys. >=20 > If I understand Sasha right, He is referring to what in E/R=20 > we used to call > identifying relationships. This is where one entity is=20 > dependent on another > in such a way that the foreign key becomes part of the=20 > primary key. If this > is a 1-1 relationship, there is even no need for an=20 > additional identifier, > therefore it should be sufficient to have a foreign key that=20 > also serves as > primary key (the primary key is "inherited" by the dependent=20 > entity. In > fact, if you implement inheritance on top of a relational=20 > model, this is > exactly where you end up, dont you?). It would be rather=20 > inconvenient IMO if > the dependent entity had to maintain an additional primary=20 > key just for the > sake of the O/R mapping tool. >=20 > thanks, and good night, > Christian >=20 Ah, OK, now I got it.=20 This of course possible. You just have to declare the foreign-key = attribute as primary key in the XML Mapping Repository. Thomas >=20 > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > http://lists.sourceforge.net/lists/listinfo/objectbridge-developers >=20 |
|
From: Christian S. <chr...@ne...> - 2001-05-22 22:34:55
|
Hello, Hope you dont mind that I throw in my few cents here: > > SUPPORT FOR MAPPING MANY-MANY RELATIONSHIPS > > Does OJB currently support the mapping of many-to-many > > relationships? I > > didn't see any examples in the tests. If not, is this planned for an > > upcoming release? > > > You are right, there is no support for m-n relationships. You have to > decompose it into two 1-n relationships. You have to do this for your RDBMS > ER model anyway, so its not such a big problem in my eyes. > There are some OJB users (marquier et al.) who are thinking of building an > n-m extension. But right now there are no concrete plans to include such a > feature. I dont think the fact that in physical database modeling you decompose N-M relationships into separate 1-N relationships makes this a less useful (should I say crucial?) feature fo an O/R modeling tool. After all, it is the very purpose of the O/R tool to cover the technical details with a more abstract and intuitive layer. And even if I was going to program plain SQL, I would use a double join to directly access the final target entity and not load the rows of the associative table and then proceed from there. > > ASSIGNING IDENTITY VALUES > > Some of the object graphs that I will be persisting have > > dependent/related > > objects which do not have IDs. Do all objects have to have IDs when > > persisting using OJB? If so, is there a way to have OJB transparently > > assign IDs using the SequenceManager, without the client code > > needing to > > call SequenceManager.getUniqueId() for each object? If not, > > can I use a > > ConversionStrategy as a means of implementing transparent ID > > assignment? > > I'm not sure if I get you right: Your database table have no primary key > columns? Or do they have non numeric keys? Or do you have compound keys, > that contain of two or more columns? > > OJB does require to have primary keys. But they can be of arbitrary type > (not only INT) and may also be compound keys. If I understand Sasha right, He is referring to what in E/R we used to call identifying relationships. This is where one entity is dependent on another in such a way that the foreign key becomes part of the primary key. If this is a 1-1 relationship, there is even no need for an additional identifier, therefore it should be sufficient to have a foreign key that also serves as primary key (the primary key is "inherited" by the dependent entity. In fact, if you implement inheritance on top of a relational model, this is exactly where you end up, dont you?). It would be rather inconvenient IMO if the dependent entity had to maintain an additional primary key just for the sake of the O/R mapping tool. thanks, and good night, Christian |
|
From: <tho...@it...> - 2001-05-22 12:41:25
|
Hi Sasha, > -------- Original Message -------- > Subject: OJB Technical Questions & Tutorial #3 > Date: Mon, 21 May 2001 16:09:47 -0400 > From: "Sasha Haghani" <ha...@in...> > To: <th...@us...> > > Dear Thomas, > > I've been taking a deeper look at OJB, including the examples found in > the > test package, and I have a few questions about features, mapping and > identities. > > I hope these don't bother you too much ;-), but I was hoping you could > answer these for me. No problem... > > TUTORIAL #3 > On the OJB Forum on SourceForge recently, you told a user > that you were > still working on a tutorial which "demonstrates basic OJB programming > techniques". I assume this is tutorial #3. Would you also be able to > send > me a copy of this -- it might help answer many of my questions. No, I meant tutorial 2, the ODMG tutorial, which is now finished and available under http://objectbridge.sourceforge.net/tutorial2.html. This tutorial expalins how to use the OJB ODMG API. The first tutorial http://objectbridge.sourceforge.net/tutorial1.html explains the OJB PersistenceBroker API. The third tutorial covering OJB O/R mapping techniques has not been started :-( > SUPPORT FOR MAPPING MANY-MANY RELATIONSHIPS > Does OJB currently support the mapping of many-to-many > relationships? I > didn't see any examples in the tests. If not, is this planned for an > upcoming release? > You are right, there is no support for m-n relationships. You have to decompose it into two 1-n relationships. You have to do this for your RDBMS ER model anyway, so its not such a big problem in my eyes. There are some OJB users (marquier et al.) who are thinking of building an n-m extension. But right now there are no concrete plans to include such a feature. > ONE-WAY 1-MANY RELATIONSHIPS > Is it always necessary for the many related object (i.e.: Article) to > have a > reference and an ID of the parent object (i.e.: > ProductGroup). In other > words, do the relationships always have to be two-way in the Java > objects? You always need the foreign key identifier(s), to build the proper SQL statements, but there is no need to have a reference attribute. So it's quite possible to define unidirectional associations in the java objects. > Is there a way to map such a relationship where ProductGroup > would only > need > to have a Collection or array of Articles (i.e.: one-way)? Yes. just omit the attribute productGroup from the class Article and remove it's reference descriptor from the repository xml file to see it. > > Is the <descriptor_ids> tag meant to reference the field descriptor > which > stores the parent's ID in a 1-N relationship? > Exactly. <ClassDescriptor id="2"> <class.name>test.ojb.broker.ProductGroup</class.name> <class.proxy>test.ojb.broker.ProductGroupProxy</class.proxy> <table.name>Kategorien</table.name> ... ... <CollectionDescriptor id="1"> <cdfield.name>allArticlesInGroup</cdfield.name> <items.class>test.ojb.broker.Article</items.class> <descriptor_ids>4</descriptor_ids> <auto.retrieve>true</auto.retrieve> <auto.update>false</auto.update> <auto.delete>false</auto.delete> </CollectionDescriptor> </ClassDescriptor> means that the fieldDescriptor with id 4 of the class test.ojb.broker.Article is used as a foreign key: <ClassDescriptor id="1"> <class.name>test.ojb.broker.Article</class.name> ... ... <FieldDescriptor id="4"> <field.name>productGroupId</field.name> <column.name>Kategorie_Nr</column.name> <jdbc_type>INT</jdbc_type> </FieldDescriptor> We need this this to build proper WHERE - clauses. If you have compound primary keys you can use a comma separated list to denote all foreign key descriptors (e.g. <descriptor_ids>4,5,6</descriptor_ids>) > Finally in the example repository.xml for the test package, in the > <CollectionDescriptor> which appears in the mapping for the class > test.ojb.broker.ProductGroup, the collection field name on line 109 > appears > as follows: > > <cdfield.name>allArticlesInGroup</cdfield.name> > > But there is no getAllArticlesInGroup() method in ProductGroup, only > getAllArticles(), and the allArticlesInGroup member Vector is declared > as > private. So how does OJB read/write this field/property? > As you see there is no need to stick to naming conventions as in EJB. OJB does not use getters and setters to access the attributes of persistent classes. It does access exactly those attributes that are defined in the repository xml file. It does use the Java reflection API to do this, which allows to access private attributes. > ASSIGNING IDENTITY VALUES > Some of the object graphs that I will be persisting have > dependent/related > objects which do not have IDs. Do all objects have to have IDs when > persisting using OJB? If so, is there a way to have OJB transparently > assign IDs using the SequenceManager, without the client code > needing to > call SequenceManager.getUniqueId() for each object? If not, > can I use a > ConversionStrategy as a means of implementing transparent ID > assignment? I'm not sure if I get you right: Your database table have no primary key columns? Or do they have non numeric keys? Or do you have compound keys, that contain of two or more columns? OJB does require to have primary keys. But they can be of arbitrary type (not only INT) and may also be compound keys. The SequenceManager can be used to generate unique primary key values for columns of type int. There is no repository tag like <autoincrement> that triggers automatical generation of IDs, thus you have to place the SequenceManager.getUniqueId() in your client code. But if you need this feature urgently just tell me. It can be easily included in the next release. You can't use ConversionSTrategies on primarykey columns. (For performnce reasons, etc.) > > OJB TABLES AND INTERNAL MAPPINGS > Are the additional OJB tables and internal mapping always required, or > are > they only needed when using ODMG collection support? > You are right: those internal tables are only needed if you use special features. There is one table that contains the values for the SequenceManager. All other tables are used by the ODMG server. See this discussion for a documentation of the internal tables: http://sourceforge.net/forum/forum.php?thread_id=97263&forum_id=43066 HTH, Thomas |
|
From: Thomas M. <tho...@ho...> - 2001-05-13 07:43:31
|
Hi all,
I just placed a new release on the OJB site.
This release contains the longly awaited OQL Parser!
The ODMG tutorial has been touched slightly and now uses only ODMG API
calls for persistence operations.
from the release notes:
changes in this release:
New features:
- OQL Parser and OQLQuery interface are now implemented.
A few things are still missing:
- bind operation not yet implemented
- OQL filter operations in ODMG Collection not
yet implemented
changes, refactorings:
- corrections and modifications to the ODMG tutorial to
reflect the newly implemented OQL interface
- modified the semantics of the register process for ODMG
transactions: now a register also recursively registers
all associated objects (registering a root node will
register all child nodes)
- modified the semantics of ODMG transaction commit:
before an object is commited it is compared with its
internal clone to detect modifications.
- These to changes allow to get rid of the markModified
operation, which was neccessary to tell the transaction
about object changes.
The Interface PersistenceCapable has been removed to
reflect this change.
bug fixes:
Open bugs:
- Testmethods in test.ojb.odmg.OdmgExamples still report
failures. 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...
enJoy,
Thomas
|
|
From: Alex C. <ac...@in...> - 2001-05-09 16:26:21
|
From: tho...@it... [mailto:tho...@it...] > I have been contacted by several projects that would like to > use OJB but > have problems in complying to the current GLP license model of OJB. I'm assuming you meant GPL... Out of curiosity, do you know the GPL's position on Java bytecode? AFAIK if the system is unable to run without a particular library (i.e. it's "statically" linked using the "import" keyword), and the library is GPL, the system must also be GPL. If the library is optional, distributed separately and selectable via a runtime configuration option, you're okay. LGPL would obviously allow the library to be used anywhere. > My intention is to have OJB used in such projects as long as > our copyright is respected and no commercial O/R system is > build by using our code. LGPL might be your best bet; the code itself cannot be used as the basis of a proprietary library, but the library as a whole can be called on by proprietary applications. Personally, I don't really like the LGPL for this kind of project. I actually quite like what TrollTech has done with Qt, namely that it's released under both the GPL (NOT the LPGL) and the QPL. Developers who don't want to GPL their own code must buy a commercial license under the QPL, but GPL'd projects can use it freely. HTH -0xe1a |
|
From: Dixon-Peugh, D. <Dav...@tp...> - 2001-05-09 13:23:46
|
I beleive the LGPL is definitely a better fit for OJB. I have no problems changing my stuff to LGPL. I would recommend that the change happens as part of the 0.5 release, if only to say "code after 0.5 is LGPL, before is GPL". David Dixon-Peugh -----Original Message----- From: obj...@li... [mailto:obj...@li...]On Behalf Of Mahler Thomas Sent: Wednesday, May 09, 2001 7:02 AM To: Objectbridge (E-Mail) Subject: [Objectbridge-developers] OJB Licensing model Hi all, I have been contacted by several projects that would like to use OJB but have problems in complying to the current GLP license model of OJB. They are building commercial systems or systems that are licensed under Apache license etc. My intention is to have OJB used in such projects as long as our copyright is respected and no commercial O/R system is build by using our code. Do you have any ideas which open source could be more adequate for this approach? I heard that the Lesser Public Licence (LGPL) fits better to library style software. Any comments or suggestions are welcome, Thomas _______________________________________________ Objectbridge-developers mailing list Obj...@li... http://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: <tho...@it...> - 2001-05-09 11:05:27
|
Hi all, I'm quite excited about the newest feature integrated into OJB: the OQL interface. My colleague Christian took the sample OQL grammar from the ODMG site and modified it in a way that the resulting Parser transforms OQL strings into ojb.broker.query.Query Objects. These query objects can be used by the PersistenceBroker to perform database queries. I integrated this parser into the ODMG implementation and was already able to let the tutorial2 (ODMG tutorial) Application run exclusively against the ODMG API. I will include this parser into the next release. There are still a few things missing, like the query methods in the ODMG collection classes or the bind facility. Once these things are done I would like to make a major version shift from 0.1.x to 0.5.x Thomas |
|
From: <tho...@it...> - 2001-05-09 11:04:23
|
Hi all, I have been contacted by several projects that would like to use OJB but have problems in complying to the current GLP license model of OJB. They are building commercial systems or systems that are licensed under Apache license etc. My intention is to have OJB used in such projects as long as our copyright is respected and no commercial O/R system is build by using our code. Do you have any ideas which open source could be more adequate for this approach? I heard that the Lesser Public Licence (LGPL) fits better to library style software. Any comments or suggestions are welcome, Thomas |
|
From: Thomas M. <tho...@ho...> - 2001-04-29 15:43:14
|
Hi all, After spending a 2 weeks vacation cycling in Italy I found the time to assemble a new release. There are no changes to the source code, but a brand new tutorial on using the ODMG API with OJB. The tutorial application is a reimplementation of the first tutorial app, demonstrating the use of the ODMG API in the Use Case implementations. I finally found a volunteer for the OQL parser. There is a sample OQL grammar on the ODMG website for the ANTLR parser generator and we are trying to modify it for usage in the OJB system. It's still work in progress and does not even compile, therefore I did not include anything in this source release. But if you want to have a look or want to help just ask me I'll send you what we have done already. ciao, Thomas |
|
From: Thomas M. <tho...@ho...> - 2001-03-31 18:45:18
|
Hi all, After struggling with a harddisk-crash that almost destroyed 2 weeks of work I finally managed to assemble a new release. changes in this release: New features: - User defined Type- and Value mappings are now configurable per class. changes, refactorings: - refactored the PersistenceBroker to use Arrays instead of Vectors for all timecritical internal operations - ojb.broker.query.Criteria.toString() now generates better readable statements bug fixes: - corrections to OJBSearchFilter (thanks to Sascha) - fixed an annoying bug in the XmlRepositoryHandler that somtimes damaged tokens (thanks to Andrew) - PersistenceBrokerImpl.store(...) does now handle null-values properly (thanks to Andrew) - RsIterator.hasNext() now also checks ResultSet.isAfterLast() (thanks to Andrew) Open bugs: - Testmethods in test.ojb.odmg.OdmgExamples still report failures. in my development environment (VisualAge) I can't reproduce them... enJoy, Thomas |
|
From: Thomas M. <tho...@ho...> - 2001-03-16 21:33:54
|
dear OJB developers, I just rolled out a new release. As you can see from the build number it does not contain much changes to the last release 0.1.98. The only things added are - a tutorial application in package test.ojb.tutorial1 - a tutorial document on basic techniques using OJB as a persistence layer. (see http://objectbridge.sourceforge.net/tutorial1.html for details) I hope you find it useful! regards, Thomas |
|
From: Thomas M. <tho...@ho...> - 2001-03-03 14:10:24
|
Dear ObJectBridge enthusiasts, I'd like to inform you about the latest OJB release. The new release contains three major enhancements: 1. ODMG Collections and DMap are now fully implemented 2. The PersistenceBroker now provides a transaction API. A transaction can be started with PersistenceBroker::beginTransaction(), aborted with ::abortTransaction() and commited with ::commitTransaction(). Usage of this transaction mechanism can improve overall performance by a factor of 3 - 4. Distributed transaction against multiple RDBMS are not yet managed properly 3. 1-n relations can now also be implemented with Arrays. OJB does now provide a rich set of choices for implementing 1-n relations: - Java Arrays, - Java Collections - ODMG Collections - user defined Collections implementing the interface ManageableCollection Here is a list of all changes from the release notes: New features: - Now all Collections required by ODMG are implemented: DSet, DBag, DList DArray - The DMap ODMG persistent map is now also implemeted. - added support for using arrays to model 1-n relations. - new method RsIterator::releaseDbResources() can be used to free the JDBC resources used by the RsIterator objects - added OJBSearchFilter from OpenEMed project (credits to Sascha) - Use JAXP Parser factory to create SAX Parser - Transaction support in PersistenceBroker changes, refactorings: - proper handling of ClassNotPersistenceCapableExceptions - PersistenceBrokerImpl::getObjectByQuery() now also works with QueryByCriteria - move package examples to package test - removed quoting of column names Open bugs: - Testmethods in test.ojb.odmg.OdmgExamples still report failures. in my development environment (VisualAge) I can't reproduce them... More information is available at http://objectbridge.sourceforge.net I have interesting news for all that are in doubt if OJB's dynamic architecture is fit for prime time applications: One development team in my company made a performance comparison between TOPLink and OJB. Their tests were based on batch oriented scenarios, that have to do a lot of insert and update work. OJB (using the new transaction API) was about 20% faster than TOPLink! Not bad for a 0$ product ;-) David is thinking about providing JTA transaction support. This will help to integrate OJB in complex distributed applications. I'm planning to implement the OQL Query language in one of the next releases. This is the last feature missing for full ODMG compliance. I'm also planning to build a servlet based server around the PersistenceBroker. This will allow to run OJB as a server and to run multiple clients from physically separated machines against OJB. If you have any ideas, comments, additional features or want to contribute some code, don't hesitate to contact me. thanks, Thomas |
|
From: Thomas M. <tho...@ho...> - 2001-02-19 15:14:00
|
Dear ObJectBridge fans, I just assembled a new release and put it on the SourceForge download area. In the last two weeks I tried to assist Sascha Koenig, who is evaluating OJB for the OpenEMed project (http://OpenMed.sourceforge.net/), in getting a sample application running using OJB. He discovered some bugs had not been covered by JUnit tests. And he also detected conceptual deficiencies that only showed up due to special requirements of the data structures in his application. Such "real-world" experience is necessary to find other bugs, defects, missing features, etc. Therefore I'd like to invite YOU to use OJB in your applications. Thanks for your feedback! >From the release-notes: New features: - Support for user defined collections. It is now possible to use user defined collections (e.g. typed collections) as Collection attributes. These collections must implement the interface ojb.broker.ManageableCollection to provide minimum interoperability with the PersistenceBroker mechanisms. There is a new TestClass test.ojb.broker.TypedCollectionTest testing and demonstrating all relevant techniques. - There is a first fully functional ODMG Collection: Dlist. It's implemented by ojb.server.collections.DListImpl. There is a TestClass test.ojb.odmg.DListTest testing and demonstrating the usage of this collection. changes, refactorings: - Complete redesign of the ODMG Transaction-mechanism. I unified the concepts of David's TransactionWrapper objects with my idea of ObjectModification objects, that had been responsible for different aspects of the transaction management in OJB. - Removed interface IPobject and baseclass Pobject. These were meant as examples for encapsulating PersistenceBroker code in business objects. I don't want to encourage such a poor design any longer... - Collection attributes can now be defined without reverse ReferenceAttributes. This design was based on the wrong assumption, that there is always a unique ReferenceAttribute describing the foreignkey relation betweeen the involved tables. Now Collection Attributes can be defined without specifying an inverse reverse ReferenceAttribute. To make this possible it's now necessary to specify the list of foreign key attributes (respectively their Descriptor Ids) within the CollectionDescriptor. - Harmonized the syntax for ReferenceDescriptors and CollectionsDescriptors in the repository.dtd. Now <auto.retrieve>, <auto.update>, <auto.delete> can be used in both classes. Usage of these tags is now optional. If <auto.retrieve> is ommited, true is the default value. If <auto.update>, <auto.delete> default value is false. bug fixes: - storing of collection attributes did not work due to an error during the last refactoring. No JUnit test detected the error :-( Thanks to Sascha Koenig for reporting this bug. Open bugs: - Testmethods in test.ojb.odmg.OdmgExamples still report failures. in my development environment (VisualAge) I can't reproduce them... kind regards, Thomas |
|
From: Dixon-Peugh, D. <Dav...@tp...> - 2001-02-12 14:13:33
|
Sounds good. I was basically trying to come up with some solutions for Insert and Delete. (The old way was basically only for updates, and with the new code you had, I realized I needed to handle Insert and Delete as well. I guess I didn't think too far ahead when I coded that stuff up.) David. -----Original Message----- From: tho...@it... [mailto:tho...@it...] Sent: Monday, February 12, 2001 5:57 AM To: Dixon-Peugh, David Cc: objectbridge Subject: ODMG Transaction Management Hi David, Hi all, During the last weeks I've been working on an implementation for ODMG persistent collections. My first aim was a DList implementation which is working quite well already. During this work I found some bugs in the transaction mangement classes and also some code doubling and incoherent pieces of code. I'd like to improve this basic functionlity before working on the other collection classes. I like your idea of TransactionWrapper objects. They are a great help in building event mechanisms and holding shadow copies for restoring objects on a tx.abort(). But I see a problem which cannot be solved easily. There are three concrete subclasses InsertTransactionWrapper, DeleteTransactionWrapper, UpdateTransactionWrapper. Let's assume mark an object for update, that is we place it in a UpdateTransactionWrapper. Now assume the client app wants to mark the same object for deletion. What will happen? I do not see any solution for this in your code. Doing such a state transition using your classes will need something like the following: - remove the UpdateTransactionWrapper from the TransactionImpl's updateObjectList. - create a DeleteTransctionWrapper object - place it in the deleteObjectList Of course this it's possible to implement this functionality but involves a lot of searching through the getAllObjects() list. Also each state transition involves discarding one wrapper and creating a new one. I addressed these state transitions explicitly in the ModificationState and its subclasses. The ModificationState subclasses are also responsible for commit(), abort() and checkpoint() by implementing the adequate persistence operations. (These classes apply the state pattern and the command pattern.) A related problem: you did not implement update, insert and delete logic in your wrapper objects but delegate this to my ObjectStateTable. The delegation as such is not a problem, but for each object under transaction management we now need 1 ObjectTransactionWrapper and 1 ObjectModification object. Here is my solution: Let's merge the classes ObjectTransactionWrapper and ObjectModification: 1. Remove subclasses of ObjectTransactionWrapper. 2. make ObjectTransactionWrapper concrete 3. add an attribute state of type ModificationState. 4. get rid of my ObjectModification class. 5. maintain only one list of TransactionWrapper table in the TransactionImpl If you don't have any objections I'd like to implement this design in the next days. Please tell me what you think and tell me if you have further suggestions. thank you, Thomas |
|
From: <tho...@it...> - 2001-02-12 13:11:55
|
Hi David, Hi all, During the last weeks I've been working on an implementation for ODMG persistent collections. My first aim was a DList implementation which is working quite well already. During this work I found some bugs in the transaction mangement classes and also some code doubling and incoherent pieces of code. I'd like to improve this basic functionlity before working on the other collection classes. I like your idea of TransactionWrapper objects. They are a great help in building event mechanisms and holding shadow copies for restoring objects on a tx.abort(). But I see a problem which cannot be solved easily. There are three concrete subclasses InsertTransactionWrapper, DeleteTransactionWrapper, UpdateTransactionWrapper. Let's assume mark an object for update, that is we place it in a UpdateTransactionWrapper. Now assume the client app wants to mark the same object for deletion. What will happen? I do not see any solution for this in your code. Doing such a state transition using your classes will need something like the following: - remove the UpdateTransactionWrapper from the TransactionImpl's updateObjectList. - create a DeleteTransctionWrapper object - place it in the deleteObjectList Of course this it's possible to implement this functionality but involves a lot of searching through the getAllObjects() list. Also each state transition involves discarding one wrapper and creating a new one. I addressed these state transitions explicitly in the ModificationState and its subclasses. The ModificationState subclasses are also responsible for commit(), abort() and checkpoint() by implementing the adequate persistence operations. (These classes apply the state pattern and the command pattern.) A related problem: you did not implement update, insert and delete logic in your wrapper objects but delegate this to my ObjectStateTable. The delegation as such is not a problem, but for each object under transaction management we now need 1 ObjectTransactionWrapper and 1 ObjectModification object. Here is my solution: Let's merge the classes ObjectTransactionWrapper and ObjectModification: 1. Remove subclasses of ObjectTransactionWrapper. 2. make ObjectTransactionWrapper concrete 3. add an attribute state of type ModificationState. 4. get rid of my ObjectModification class. 5. maintain only one list of TransactionWrapper table in the TransactionImpl If you don't have any objections I'd like to implement this design in the next days. Please tell me what you think and tell me if you have further suggestions. thank you, Thomas |
|
From: Thomas M. <tho...@ho...> - 2001-02-03 23:10:49
|
Dear OJB fans, <hype> there's a brand new release waiting for you with a bunch of new and interesting features! </hype> The new Version brings two major enhancements: - first step towards persistent collections (a DList is already working) - Full support for polymorphisms and extents. New features: - Support for polymorphism. It is now possible to define extents consisting of several subclasses. The mechanism supports Interfaces as well as base-classes. There are still things that don't support polymorphism: PersistenceBroker.getIteratorByQuery and PersistenceBroker.getPkEnumerationByQuery. (They are Wrappers to JBDC ResultSets and I have no idea how to make ResultSets polymorph ;-) There is a new TestClass test.ojb.broker.PolymorphicExtents testing and demonstrating all relevant techniques. - first step towards persistent Collection implementation. I started with a DListImpl. Right now it does not implement more than add(), but persistence support should work... - A SequenceManager responsible for generating unique values for primary-key columns. This class is aware of extents and maintains uniqueness of pk-values accross any number of tables. changes: - class ojb.broker.query.Criteria allows adding of more filtering criteria. (credits to Sascha) Open bugs: - Two testmethods in test.ojb.odmg.OdmgExamples still report failures. in my development environment (VisualAge) I can't reproduce them... I hope everything works as expected... If something is missing or does not work, just drop me a line. enJoy, Thomas |
|
From: Sascha A. K. <Ko...@un...> - 2001-02-01 23:57:07
|
In the ojb.broker.query.Criteria class I'm missing the methods for = notEqual, like, greaterEqual and lessEqual. The helper classes are actually in the package, but the methods to add = them to a Criteria object are missing (only addEqualTo, addGreaterThan = and addLessThan are defined). Can you take a look at it? Thanks Sascha __________________________ Sascha A. Koenig CCS-1, MS B287 Computer and Computational Sciences Los Alamos National Laboratory Los Alamos, NM 87545 phone: +1 (505) 665-6057 cellular: +1 (505) 670-4643 fax: +1 (505) 665-4939 http://telemed.lanl.gov/OpenEMed=20 |
|
From: Sascha A. K. <Ko...@un...> - 2001-02-01 15:56:21
|
that sounds really good. When do you think you could have a first =
version ready?
An id for subtables is not a restriction, we would need that anyway if =
we don't want to store everything in the main table.
Thanks a lot
Sascha
----- Original Message -----=20
From: David Forslund=20
To: Mahler Thomas ; objectbridge=20
Sent: Wednesday, January 31, 2001 5:28 PM
Subject: Re: [Objectbridge-developers] RE: [objectbridge - Open =
Discussion] Polymorphism support?
At 04:41 PM 1/31/2001 +0100, Mahler Thomas wrote:
Hi Sascha,
> -----Urspr=FCngliche Nachricht-----
> Von: nobody [mailto:no...@so...]
> Gesendet: Dienstag, 30. Januar 2001 22:31
> An: no...@so...
> Betreff: [objectbridge - Open Discussion] Polymorphism support?
>
>
> Read and respond to this message at:
> http://sourceforge.net/forum/message.php?msg_id=3D103071
> By: koenig
>
> Hi,
>
> I looked into ObjectBridge as a O/R mapping tool for our OpenEMed =
project
> (http://telemed.lanl.gov/OpenEMed).
>
Thanks for your interest! It would be a great opportunity to proof =
the
usability of OJB if it could solve your persistence needs.
> Unfortunately I didn't found a mechanism for supporting polymorph
> objects.
You are right. As of today there is no support for Polymorphism.
But of course it is an essential feature. It is also required by the =
ODMG
spec.
If it is a feature you need urgently I can start to work on it =
immediately.
I have already a design in mind, so it will take only a few days...
We urgently need this feature. Our only other option in open source =
is castor.
>
> In particular:
> Our main class has a field 'value' of an interface type. This
> interface type
> is implemented by several concrete classes that get stored in the
> 'value' field
> of the main object.
> I'd like to store these objects in separate tables referenced
> from the main
> object, but even storing them as embedded objects would be fine.
>
> Is there a way to do this with ObjectBridge?
As long as I'm not finished with a real solution, you could try the
following:
you can use an additional field 'valueOID' of type String which =
takes a
serialized
representation of the concrete values Identity:
valueOID =3D new Identity(value).serialize();
instead of making the field value persistent you store the =
serialized OID in
a db column.
Of course your value field is then transient. On loading your Object =
you
have to reconstruct it e.g. in a constructor by:
value =3D (YourInterface)
broker.getObjectByIdentity(Identity.forName(valueOID));
I'm using this approach for untyped Collections (like =
org.odmg.DList) and it
works quite well. But of course it's not type safe and brings one =
additional
level of indirection into the mapping...
Of course you can also store complete serialized "embedded" objects =
in a
single db column, but this is even worse from a design point of =
view...
The difficulty with what you suggest is that we are trying to do all =
of this through=20
an interface that lets us talk to multiple database sources. So we =
need a "generic" solution
that we don't have to wire much into our objects. We are willing to =
do some specializations (such as
implementing the Persistent interface), but don't like to have to get =
into the details of the objects much.
Thanks,
Dave
best regards,
Thomas
_______________________________________________
Objectbridge-developers mailing list
Obj...@li...
http://lists.sourceforge.net/lists/listinfo/objectbridge-developers
David W. Forslund dw...@la... =20
Computer and Computational Sciences =
http://www.acl.lanl.gov/~dwf
Los Alamos National Laboratory Los Alamos, NM 87545 =
=20
505-665-1907 FAX: 505-665-4939
|
|
From: <tho...@it...> - 2001-02-01 12:36:13
|
Hi David,
-----Urspr=FCngliche Nachricht-----
Von: David Forslund [mailto:dw...@la...]
Gesendet: Donnerstag, 1. Februar 2001 01:28
An: Mahler Thomas; objectbridge
Betreff: Re: [Objectbridge-developers] RE: [objectbridge - Open
Discussion] Polymorphism support?
At 04:41 PM 1/31/2001 +0100, Mahler Thomas wrote:
Hi Sascha,
> -----Urspr=FCngliche Nachricht-----
> Von: nobody [mailto:no...@so...]
> Gesendet: Dienstag, 30. Januar 2001 22:31
> An: no...@so...
> Betreff: [objectbridge - Open Discussion] Polymorphism support?
>
>
> Read and respond to this message at:
> http://sourceforge.net/forum/message.php?msg_id=3D103071
> By: koenig
>
> Hi,
>
> I looked into ObjectBridge as a O/R mapping tool for our OpenEMed
project
> (http://telemed.lanl.gov/OpenEMed).
>
Thanks for your interest! It would be a great opportunity to proof th=
e
usability of OJB if it could solve your persistence needs.
> Unfortunately I didn't found a mechanism for supporting polymorph
> objects.
You are right. As of today there is no support for Polymorphism.
But of course it is an essential feature. It is also required by the
ODMG
spec.
If it is a feature you need urgently I can start to work on it
immediately.
I have already a design in mind, so it will take only a few days...
We urgently need this feature. Our only other option in open source is
castor.
After finishing a first draft of a persistent collection implementation I
started working on support for polymorphism yesterday.
May solution will work for interfaces implemented by several classes or w=
ith
a baseclass extended by several other classes.
It will work for Collections as well as for simple references.
There is only one impact on the application:
Assume we have an Interface I implemented by classes X, Y and Z. X, Y, Z
that are mapped to three different tables TX, TY, TZ. All these tables ha=
ve
a primary key column ID.
Further we have a business class B (mapped to TB) with an attribute value=
of
Type I. We also need a private attribute value_id holding the foreign key=
ID
of one of the tables TX, TY, TZ.
This will work only if ID's are unique across all tables representing
objects of Type I.
There will be a class SequenceManager with a static method getUniqueId(..=
.)
that is responsible for generating such unique numbers, so the impact on
your app's code we be pretty small...
Right now I don't have a precise Idea how to extend the Query engine to
search through polymorphic Extends. Any Ideas are welcome!
>
> In particular:
> Our main class has a field 'value' of an interface type. This
> interface type
> is implemented by several concrete classes that get stored in the
> 'value' field
> of the main object.
> I'd like to store these objects in separate tables referenced
> from the main
> object, but even storing them as embedded objects would be fine.
>
> Is there a way to do this with ObjectBridge?
As long as I'm not finished with a real solution, you could try the
following:
you can use an additional field 'valueOID' of type String which takes=
a
serialized
representation of the concrete values Identity:
valueOID =3D new Identity(value).serialize();
instead of making the field value persistent you store the serialized
OID in
a db column.
Of course your value field is then transient. On loading your Object =
you
have to reconstruct it e.g. in a constructor by:
value =3D (YourInterface)
broker.getObjectByIdentity(Identity.forName(valueOID));
I'm using this approach for untyped Collections (like org.odmg.DList)
and it
works quite well. But of course it's not type safe and brings one
additional
level of indirection into the mapping...
Of course you can also store complete serialized "embedded" objects i=
n a
single db column, but this is even worse from a design point of view.=
..
The difficulty with what you suggest is that we are trying to do all of
this through
an interface that lets us talk to multiple database sources. So we ne=
ed
a "generic" solution
that we don't have to wire much into our objects. We are willing to do
some specializations (such as
implementing the Persistent interface), but don't like to have to get i=
nto
the details of the objects much.
I totally agree with you. This was only meant as a "quick hack" for getti=
ng
some examples running.
So I hope to get something running within the next days and will keep you
informed.
Thomas
Thanks,
Dave
best regards,
Thomas
_______________________________________________
Objectbridge-developers mailing list
Obj...@li...
http://lists.sourceforge.net/lists/listinfo/objectbridge-developers
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: David F. <dw...@la...> - 2001-02-01 00:28:30
|
At 04:41 PM 1/31/2001 +0100, Mahler Thomas wrote: >Hi Sascha, > > > -----Urspr=FCngliche Nachricht----- > > Von: nobody [mailto:no...@so...] > > Gesendet: Dienstag, 30. Januar 2001 22:31 > > An: no...@so... > > Betreff: [objectbridge - Open Discussion] Polymorphism support? > > > > > > Read and respond to this message at: > > http://sourceforge.net/forum/message.php?msg_id=3D103071 > > By: koenig > > > > Hi, > > > > I looked into ObjectBridge as a O/R mapping tool for our OpenEMed= project > > (http://telemed.lanl.gov/OpenEMed). > > >Thanks for your interest! It would be a great opportunity to proof the >usability of OJB if it could solve your persistence needs. > > > Unfortunately I didn't found a mechanism for supporting polymorph > > objects. > >You are right. As of today there is no support for Polymorphism. >But of course it is an essential feature. It is also required by the ODMG >spec. >If it is a feature you need urgently I can start to work on it immediately. > >I have already a design in mind, so it will take only a few days... We urgently need this feature. Our only other option in open source is= castor. > > > > In particular: > > Our main class has a field 'value' of an interface type. This > > interface type > > is implemented by several concrete classes that get stored in the > > 'value' field > > of the main object. > > I'd like to store these objects in separate tables referenced > > from the main > > object, but even storing them as embedded objects would be fine. > > > > Is there a way to do this with ObjectBridge? > >As long as I'm not finished with a real solution, you could try the >following: >you can use an additional field 'valueOID' of type String which takes a >serialized >representation of the concrete values Identity: >valueOID =3D new Identity(value).serialize(); >instead of making the field value persistent you store the serialized OID= in >a db column. >Of course your value field is then transient. On loading your Object you >have to reconstruct it e.g. in a constructor by: >value =3D (YourInterface) >broker.getObjectByIdentity(Identity.forName(valueOID)); > >I'm using this approach for untyped Collections (like org.odmg.DList) and= it >works quite well. But of course it's not type safe and brings one= additional >level of indirection into the mapping... > >Of course you can also store complete serialized "embedded" objects in a >single db column, but this is even worse from a design point of view... The difficulty with what you suggest is that we are trying to do all of=20 this through an interface that lets us talk to multiple database sources. So we need a= =20 "generic" solution that we don't have to wire much into our objects. We are willing to do=20 some specializations (such as implementing the Persistent interface), but don't like to have to get into= =20 the details of the objects much. Thanks, Dave >best regards, > >Thomas > > >_______________________________________________ >Objectbridge-developers mailing list >Obj...@li... >http://lists.sourceforge.net/lists/listinfo/objectbridge-developers 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: <tho...@it...> - 2001-01-31 16:32:16
|
Hi Sascha, > -----Urspr=FCngliche Nachricht----- > Von: nobody [mailto:no...@so...] > Gesendet: Dienstag, 30. Januar 2001 22:31 > An: no...@so... > Betreff: [objectbridge - Open Discussion] Polymorphism support? > > > Read and respond to this message at: > http://sourceforge.net/forum/message.php?msg_id=3D103071 > By: koenig > > Hi, > > I looked into ObjectBridge as a O/R mapping tool for our OpenEMed proje= ct > (http://telemed.lanl.gov/OpenEMed). > Thanks for your interest! It would be a great opportunity to proof the usability of OJB if it could solve your persistence needs. > Unfortunately I didn't found a mechanism for supporting polymorph > objects. You are right. As of today there is no support for Polymorphism. But of course it is an essential feature. It is also required by the ODMG spec. If it is a feature you need urgently I can start to work on it immediatel= y. I have already a design in mind, so it will take only a few days... > > In particular: > Our main class has a field 'value' of an interface type. This > interface type > is implemented by several concrete classes that get stored in the > 'value' field > of the main object. > I'd like to store these objects in separate tables referenced > from the main > object, but even storing them as embedded objects would be fine. > > Is there a way to do this with ObjectBridge? As long as I'm not finished with a real solution, you could try the following: you can use an additional field 'valueOID' of type String which takes a serialized representation of the concrete values Identity: valueOID =3D new Identity(value).serialize(); instead of making the field value persistent you store the serialized OID= in a db column. Of course your value field is then transient. On loading your Object you have to reconstruct it e.g. in a constructor by: value =3D (YourInterface) broker.getObjectByIdentity(Identity.forName(valueOID)); I'm using this approach for untyped Collections (like org.odmg.DList) and= it works quite well. But of course it's not type safe and brings one additio= nal level of indirection into the mapping... Of course you can also store complete serialized "embedded" objects in a single db column, but this is even worse from a design point of view... best regards, Thomas |
|
From: Thomas M. <tho...@ho...> - 2001-01-28 13:35:17
|
Dear OJB enthusiasts, I just assembled a new release. It brings two major enhancements: 1. A Query facility in package ojb.broker.query. It is based on the COBRA query facility. But provides some enhancements, e.g. Query-By-Examples. You will find sample code using the new API in test.ojb.broker.PersistenceBrokerTest. Joins are not supported right now... ...still a long way to OQL... 2. A re-implementation of the named roots-map (NRM). relies on Davids last changes to transaction management. The NRM is implemented as a set of Entry-objects mapped to a table in a RDBMS. This allows to apply the same transactional mechanisms as for other persistence-capable objects. This is also a first step towards an implementation of persistent Collections which will be implemented in a similar style. From the release notes: New features: - Query facility in the PersistenceBroker, allows queries by example and queries by filter criteria. In this release joins are not supported. I'm planning to use this query facility as a backend to the OQL implementation. - New TestClass test.ojb.broker.PerformanceTest allows profiling to detect performance critical operations. try "build performance". changes, refactorings - reimplemented the Named Roots Map as a persistent Collection. It is now complety integrated in the transaction mechanism. - changed the PersistenceBroker interface to reflect the usage of Query objects. changed all examples accordingly. - All PersistenceBroker Object are now declared as "throws PersistenceBrokerException" - faster implementation of ojb.broker.metadata.ClassDescriptor::getFieldDescriptorByIndex(int) bug fixes - prepared statement generation for String attributes in SQLGenerator Open bugs: - The testmethod testWrongDbName in test.ojb.odmg.OdmgExamples still reports a failure. enJoy, Thomas |
|
From: <tho...@it...> - 2001-01-24 16:30:52
|
>
>
> I picked up a bit with the NamedRoots thing. (Check for NULL,
> moved the txAbort and txCommit into doCommit, doAbort. Moved
> the DbImpl declaration to the head of the file, etc.)
The Named roots has been one of my feared quick hacks :-)
I did not include tx support for the following reason: To have tx support
for the named roots, they have to be treated as ordinary objects managed by
the odmg server. So the most natural thing would be to store them in a
special database table
e.g. with the following DDL
create table OJB_NAMED_ROOTS
(
name VARCHAR NOT NULL PRIMARY KEY,
oid VARCHAR
)
But I was not sure if it legitimate to mix the business tables with the OJB
internal tables.
If we want to implement ODMG collections like DMap we also need special
tables in one of the target databases.
When I'm thinking about this today I don't see why this should be a problem,
so I gues it would be the best thing to implement the named roots as
ordinary objects managed by the default tx mechanism and map them to a
special table.
All we have to give to our users is a DDL script to generate the required
table in their target db and a mapping in the repository XML.
>
> I also created three classes:
> UpdateTransactionWrapper
> InsertTransactionWrapper
> DeleteTransactionWrapper
>
> These all extend ObjectTransactionWrapper (with the Update specific
> stuff moved to UTW)
I don't know if this collides with my approach of the ObjectStateTable and
the ModificationStates (applying the state pattern here) ?
>
> These will be responsible for committing individual objects which
> have been part of the transaction.
>
> As for how to do this with the broker code, I'm not sure.
I would suggest rely on the following
broker.beginTransaction()
try
{
while (moreObjectsToCommit)
{
broker.store(nextObjectToCommit);
}
broker.commitTransaction();
}
catch (Throwable t)
{
broker.abortTransaction();
}
best regards,
Thomas
|
9 messages has been excluded from this view by a project administrator.
