Hey, I think that will work well for class level cacheable mark. Repository level cacheability ould still require a change...
Corey -----Original Message----- From: Thomas Mahler [mailto:[EMAIL PROTECTED]] Sent: Friday, October 11, 2002 12:42 PM To: OJB Users List Subject: Re: [Cache] Marking a Non-Cacheable at Class or Repository Scope. .. Hi Corey, Did you notice that the OJB repository.dtd now allows to have user defined attributes on class-descriptor and field-descriptor level? syntax is like follows: <attribute attribute-name="color" attribute-value="blue" /> here is sample code from CustomAttributesTest: /** Test storing repository.*/ public void testReadCustomAttributes() { DescriptorRepository repository = DescriptorRepository.getDefaultInstance(); ClassDescriptor cld = repository.getDescriptorFor(Article.class); assertTrue("blue".equals(cld.getAttribute("color"))); assertTrue("big".equals(cld.getAttribute("size"))); FieldDescriptor fld = cld.getFieldDescriptorByName("isSelloutArticle"); assertTrue("green".equals(fld.getAttribute("color"))); assertTrue("small".equals(fld.getAttribute("size"))); } It would be great if your solution would use this feature. This will reduce the necessary changes if we decide to integrate this feature into the main distribution. It will also reduce your efforts to implement your own configuration stuff! cheers, Thomas Corey Klaasmeyer wrote: > 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]> > > > > -- 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]>
