I neglected to mention, that I need this functionality, and will implement it as a custom Cache. Obviously, this will not allow Repository level configuration or be configureable in any OJB standard way.
Corey -----Original Message----- From: Corey Klaasmeyer [mailto:[EMAIL PROTECTED]] Sent: Friday, October 11, 2002 12:29 PM To: 'OJB Users List' Subject: [Cache] Marking a Non-Cacheable at Class or Repository Scope... In some cases, I think it might be useful mark classes non-cacheable by repository or class. For instance, if repository is used outside of OJB, the instance may become dirty after external modification of the repository. Conversely, cacheing may be used in a repository not modified outside of OJB. Repository level control would be useful, and could be implemented fairly easily in the the PersistenceBroker implementation. Per-class markers would have to be implemented in an ObjectCacheCacheableClass implementation and made configurable as an element <class-descriptor> in the repository_user.xml. Would this be useful to others? It would allow multiple database users to configure cacheing without implementing a custom Cache, or turning it off altogether. Does this make sense? I can implement any or all. Corey -----Original Message----- From: Ron Gallagher [mailto:[EMAIL PROTECTED]] Sent: Friday, October 11, 2002 10:17 AM To: OJB Users List Subject: Re: Can OJB use stored procedures? Graham -- Out of the box, ojb doesn't support using stored procedures. However, Thomas has already incoporated some enhancements to the repository dtd and the repository handlers that allow me to use oracle packages/procedures to perform all inserts, updates and deletes. These enhancemnets allow me to add 'custom attributes' to the class-descriptor and field-descriptor elements. At the class-descriptor level, these attributes allow me to indicate what package/procedure should be used to do an insert, update or delete. At the field-descriptor level, these custom attributes allow me to know which fields will be returned to me by the procedure when we do an insert or an update. I'm not using packages/procedures for any selects. These are still handled by ojb, without modification. Here's a scaled down example of one of our class-descriptors: <class-descriptor class="..." table="CONTRACT"> <field-descriptor column="CONTRACT_ID"...> <attribute attribute-name="return-on-insert" attribute-value="true"/> </field-descriptor> <field-descriptor column="DATE_CREATED" ...> <attribute attribute-name="return-on-insert" attribute-value="true"/> </field-descriptor> <field-descriptor column="DATE_UPDATED" ...> <attribute attribute-name="return-on-insert" attribute-value="true"/> <attribute attribute-name="return-on-update" attribute-value="true"/> </field-descriptor> <attribute attribute-name="insert-proc" attribute-value="CONTRACT_PKG.ADD"/> <attribute attribute-name="update-proc" attribute-value="CONTRACT_PKG.CHANGE"/> <attribute attribute-name="delete-proc" attribute-value="CONTRACT_PKG.DELETE"/> </class-descriptor> In order to use these attributes, I had to extend some of the ojb classes. The key extensions were to the SqlGenerator, StatementsForClassImpl, StatementManager, JdbcAccess and PersistenceBrokerImpl classes. * SqlGenerator was extended to utilize some custom statement generators, replacements for SqlInsertStatement, SqlUpdateStatement and SqlDeleteByPkStatement. * StatementsForClassImpl was extended so that it could create CallableStatements, rather than PreparedStatements. * StatementManager was extended for two reasons: (1) so that it would utilize my extension to StatementsForClassImpl and (2) so that it could register output parameters on the CallableStatements that were created by my extension to StatementsForClassImpl. * JdbcAccess was extended so that whenever insert or update statements were executed, we could 'harvest' the output parameters that were returned by the package/stored procedure. * PersistenceBrokerImpl was extended in order for it to utilize my extensions to JdbcAccess and StatementManager. Suporting all of this behind the scenes is an oracle package that provides the actual insert, update and delete mechanics. During the insert process, this package assigns the id value (contract_id) via an oracle sequence and returns the assigned value to the caller (ojb). The date created/updated are assigned the current system date and also returned to the caller during an insert. During an update operation, the package updates the 'date updated' and returns that to the caller. I believe Thomas is in the process of implementing some additional pluggable components that will make the process I've gone through a little easier. Once those enhancements are complete, I'll rework my extensions to utilize them. Once that's complete, I'll work with Thomas on getting my extensions posted to the contributions area. HTH Ron Gallagher Atlanta, GA [EMAIL PROTECTED] > > From: "Graham Lounder" <[EMAIL PROTECTED]> > Date: 2002/10/11 Fri AM 10:41:21 EDT > To: "OJB Users List" <[EMAIL PROTECTED]> > Subject: Can OJB use stored procedures? > > Hi all, > > Simple question, does OJB 0.9.7 support stored procedures? I know Thomas > answered a similar question back in July. At that time, there was no > support for this with the exception of using QueryBySQL. Has this fact > changed with the latest release? > > Thanks in advance, > Graham > > ============================================ > Graham Lounder > Java Developer > Spatial Components Division > CARIS > 264 Rookwood Ave > Fredericton NB E3B-2M2 > Office 506 462-4263 > Fax 506 459-3849 > [EMAIL PROTECTED] > http://www.spatialcomponents.com > ============================================ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
