Hi again Robert, Robert S. Sfeir wrote:
Thomas,the name of the reference attribute. corresponding to the name in the repository.xml
I get this:
PersistenceBroker broker = null;
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
ClassDescriptor cd = broker.getClassDescriptor( HomeBO.class );
ObjectReferenceDescriptor ord = cd.getObjectReferenceDescriptorByName(???);//??? because there is no explanation in the API as to WHICH name we need to use.
If there is a reference attribute "productGroup" in your class, there will the following reference-descriptor:
<reference-descriptor
name="productGroup"
class-ref="org.apache.ojb.broker.ProductGroup"
>
<documentation>this is the reference to an articles productgroup</documentation>
<foreignkey field-ref="productGroupId"/>
<attribute attribute-name="color" attribute-value="red" />
<attribute attribute-name="size" attribute-value="tiny" />
</reference-descriptor>
to obtain it use:
cd.getObjectReferenceDescriptorByName("productGroup");
ord.setCascadeRetrieve(false);It will! PersistenceBrokerFactory.defaultPersistenceBroker() returns the broker with all the mapping definitions.
The question is that if I'm using ODMG and I open my DB with:
...
db = odmg.newDatabase();
db.open( DBC , Database.OPEN_READ_WRITE );
...
will the PersistenceBrokerFactory.defaultPersistenceBroker(); return anything at all?
Second where I have the ??? the API has no documentation on what String value it's looking for (name has not description), but from the description of the class I'm guessing that it wants to know WHICH reference of the foreign-key who's attribute I want to assign to ord and then set its Cascade type to false... Is that correct???
explained above
The PersistenceBroker API is meant to be a micro-kernel API. One of the base design guidelines is to not expose methods that can be assembled by several calls to simpler methods.
I obviously haven't tested this yet so...
If my assumptions above are all correct, then my feature request for future version is to have a method which can apply Cascade types across the board for the whole ClassDescriptor and its related classes. I think the way you have above is fine for now, but can be quite cumbersome on tables with a lot of inverse foreign keys. (that's assuming I understood where you were sending me)
Your feature request conflicts with this guideline.
The most natural thing would be to encapsulate the different cascade policies in different role classes.
The reason I want to do this is, by the way, is because based on the user role in the application, I want to have the select update and delete behave different ways. For example if the user's role is DBA, then I want everything on and allow the DBA to cascade a delete if they want to, but if it's Joe User, then I don't even want to give them that option and have the default set to no in the repository files.
cheers,
Thomas
R --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
