mails sent today about this topic), seems very reasonable.
kr and many thanks,
guenther
-Ursprüngliche Nachricht-
Von: Armin Waibel [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 28. Februar 2005 20:56
An: OJB Users List
Betreff: Re: AW: problem with compound primary key when one key="&q
Jakob Braeuchi wrote:
hi armin,
imo we could make this checkForExistence pluggable. afaik toplink also
has this feature per class (DoesExistQuery with methods like
checkDatabaseForDoesExist, checkCacheForDoesExist,
assumeExistenceForDoesExist etc.)
This makes sense! Agree the declaration per cl
hi armin,
imo we could make this checkForExistence pluggable. afaik toplink also
has this feature per class (DoesExistQuery with methods like
checkDatabaseForDoesExist, checkCacheForDoesExist,
assumeExistenceForDoesExist etc.)
jakob
Armin Waibel schrieb:
Günther Wieser wrote:
hmm, that's bad ne
hi armin,
i found this comment in BrokerHelper#representsNull:
// TODO: Do we need this check?? String could be nullified, why should
we assume
// it's 'null' on empty string?
so it lokks like not everything is clear here.
jakob
Armin Waibel schrieb:
Günther Wieser wrote:
hmm, that's bad news for
Günther Wieser wrote:
hmm, that's bad news for me. to my understanding that means that there won't
be a change of this behaviour very soon (let's say: never)?
If you know that an object needs 'update' you could use
PB.store(obj, ObjectModificationDefaultImpl.UPDATE);
i know a workaround for my i
hmm, that's bad news for me. to my understanding that means that there won't
be a change of this behaviour very soon (let's say: never)?
i know a workaround for my implementation (using some default identifier for
locale, e.g. "DEFAULT") but that doesn't make me happy as i need to change
data PLU
