we can easiliy add custom attributes on the repository level too ! Corey Klaasmeyer wrote: > 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]> > > > >
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
