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
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
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.
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
