db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: [PB-API] Problem with assertValidPkForDelete and Long(0) as PK
Date Fri, 07 Apr 2006 18:04:38 GMT
Hi Martin,

Martin Kalén wrote:
> 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.

Agree. Nevertheless we can use custom attributes to "test" new 
features/properties or to introduce a workaround for existing bugs 
without changing the repository.dtd and integrate these properties as 
elements/attributes in the next major release.

>> 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 
> codebase
> 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

+1, but there is one thing I don't understand, you said:
 > The relaxed version works perfectly for my use-case where a primary
 > key numeric field is represented by a Java Long, is not nullable
 > but where id=0 is a valid db-value that should not trigger sequence
 > autonumbering or any delete/insert checks in OJB.

I would expect that the current version of #representsNull allows id=0 
for non-primitive fields (e.g. Long).

>> 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
> use-case...


>>> 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.

Sorry, I'm a rookie in SVN stuff.
Did you prepare your apache account?

For development I use intellij and I simply check out 
../branches/OJB_1_0_RELEASE and .../trunk from

But for example I don't know how to "diff" between /trunk and 
/branches/OJB_1_0_RELEASE in Intellij IDE - I love CVS ;-)


> And later on, what do I check out when I want to merge this with the 1.1 
> branch?
> 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...
> Regards,
>  Martin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org

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

View raw message