Yep, add an attribute, and make this change in PersistentBrokerImpl:
PersistenceBrokerImpl
...
private ObjectCache objectCache =
ObjectCacheFactory.getInstance().getObjectCache(pbKey);
...
along with the overloaded getObjectCache(pbKey) ObjectCacheFactory method.
You could also do a test at objectCache.getObjectByIdentity() in
PersistenceBrokerImpl, but the former seems cleaner.
Corey
-----Original Message-----
From: Thomas Mahler [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 11, 2002 2:26 PM
To: OJB Users List
Subject: Re: [Cache] Marking a Non-Cacheable at Class or Repository
Scope. ..
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]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
