db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Kalén <mka...@apache.org>
Subject Re: [PB-API] Problem with assertValidPkForDelete and Long(0) as PK
Date Thu, 06 Apr 2006 09:45:46 GMT
Armin Waibel wrote:
> Long time no see!

Yes, it's sure been a while! :)

>> I know that at least Armin usually does not like more attributes in 
>> repository.xml, but this time I will try to make you accept an 
>> exception to the rule. :) Since null-check configuration is very 
>> similar to conversion, I propose the following DTD change for 
>> <field-descriptor/>:
>>     The null-check attribute contains a fully qualified class name.
>>     This class must implement the interface
>>     org.apache.ojb.broker.accesslayer.NullCheck.
>>     A NullCheck can be used to implement special requirements for
>>     the definitions of a field's 'null' value as Java representation.
>>     null-check CDATA #IMPLIED
> an alternative would be to use a custom attribute "null-check" in 
> field-descriptor (then we don't need to change the dtd). But I agree 
> that a new attribute will be more transparent.

I was considering the custom attribute, but that felt a bit too much
like "untyped" properties and the documentation sort of hints that
the custom attributes are used as "property-bag" for extended or
specialized FieldDescriptor implementations.

Much like RDBMS-specific JDBC-properties set on the connection descriptor.

> What about OJB's xdoclet module, do we need to adapt the @ojb.field tag 
> too?

Yes I think so, I would need help with this (probably Tom's?) as I don't
know enough about the xdoclet part myself.

My plan was to:
1. discuss the implementation and make appropriate changes in my local 
2. update OJB-150 and check in code on 1.0.x branch for everything 
except xdoclet
3. get helt to make xdoclet additions
4. forward-port to OJB 1.1 branch
5. close OJB-150

> What about the FK fields? These fields have to reflect the same behavior 
> as the PK fields. Do you expect that the user defines the same 
> "null-check" attribute in all FK fields of the referenced objects? If 
> this is the case we should add some kind of "check" (check if the PK 
> field and FK field use the same NullCheck implementation, if not log an 
> error msg or throw an exception) when OJB collects the FK fields of a 
> reference the first time.

You're right. This needs to be consistent on "both sides" of the FK,
I will give that some thought and test different approaches on my local

>> BTW, what's the currently endorsed strategy for additions like this?
> We don't have a strategy (we decide as the case arises).

OK, so if my 5-step-plan above seems about right, could you guys give me
a short "OJB vs. SVN" 101 course? :)

What should I check out from SVN if I want to make additions that I want 
included in a future 1.0.5 maintenance release.

And later on, what do I check out when I want to merge this with the 1.1 

Locally I have made additions to "db/ojb/tags/OJB_1_0_4" to be able to
compare with results from 1.0.4 release, but I guess commits there would
actually update a tag that should be frozen?

As you have figured out now I'm a bit of a SVN rookie, stuck with CVS...


To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message