Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <443A19B3.9080209@apache.org>
Date: Mon, 10 Apr 2006 10:39:15 +0200
From: =?ISO-8859-1?Q?Martin_Kal=E9n?= <mkalen@apache.org>
Organization: ASF
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: OJB Developers List <ojb-dev@db.apache.org>
Subject: Re: [PB-API] Problem with assertValidPkForDelete and Long(0) as PK
References: <42B68B91.50109@apache.org> <42B6904E.2050002@apache.org>
 <42B6A63E.5060700@apache.org> <42B6B4C9.2090505@apache.org>
 <44329FCD.1040607@apache.org> <443471D3.2080005@apache.org>
 <4434E34A.2020402@apache.org> <4436A9B6.9040603@apache.org>
In-Reply-To: <4436A9B6.9040603@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Armin Waibel wrote:
>> 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.

True, on the other hand people that start using custom attributes
might be annoyed when the setting "moves" to an attribute in the next
release. Hmm... I see a point in both locations now (attribute vs
custom property), but tend to think that a new attribute is still my
preferred choice (it won't break anything for existing users although
it's a DTD change, since it's an addition that has a backwards-
compatible #IMPLIED choice). What's your verdict? :)

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

I didn't tell the whole truth so it's not so easy to understand...
The thing is that this field is represented in the database (Oracle 9i)
as a NUMBER with a precision that gives a Java BigDecimal
representation. There is an OJB field conversion that takes care of
BigDecimal <=> long conversion, but since FieldConversion requires
an object representation it's an intermediate Long involved.

> 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

OK, I'll start with commits on /branches/OJB_1_0_RELEASE then.

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

I hope I have figured it out by then. :)
Thanks for the OJB vs SVN primer!

Cheers,
  Martin


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