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...
+1
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?
http://apache.org/dev/version-control.html
For development I use intellij and I simply check out
../branches/OJB_1_0_RELEASE and .../trunk from
https://svn.apache.org:443/repos/asf
But for example I don't know how to "diff" between /trunk and
/branches/OJB_1_0_RELEASE in Intellij IDE - I love CVS ;-)
regards,
Armin
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
