Hi Dirk,
You are right, that part of code should be refactor.
And, I admit that many things should be done better.
The idea was separating the mapping loading
of JDO and XML. Because two parts evolves,
and each adds significant amount of specific
mapping that doesn't make sense for the other.
Castor recognize it. But, it try to avoid two objects with the
same identity, because it causes problems even one is
deleted, another one is recreated.
You can recreate the same object with the same identity.
Thomas
>that means, that there is no possibilty to replace an object in storage
>c
002 8:45 AM
>To: [EMAIL PROTECTED]
>Subject: Re: [castor-dev] Force loading from database
>
>The patch that Kevin refers to is a modification to my previous
>implementation for clearing/expiring the cache. The previous version, as
>Thomas Yip pointed out, was susceptible to deadlo
To be very
frank. I don’t see immediately need
of doing
those things, even for the points I agree.
I think
getting what is in the commonly request list is
enough for
me to worry. If those are not done, I don’t
really see
people are going to keep using Castor JDO
in the
futu
>If we're only looking at removing objects
>from the cache, then you are correct.
First, I don't see value of having distributed
cache right now. That's so much more things
to optimize. That will give much more noticeable
different. If you are talking about very long term,
then I really not
>1. Read only objects, cache unlimited. They shouldn't
>be locked, so for them distributed cache should work
>just broadcasting updates.
I don't think it is true. You probably mean something
else when you say lock.
All objects that involve in a transaction must be locked.
Please take a deeper l
Hi Werner,
See inline.
>(1)
>
>The design of
> interface Database
> class DatabaseImpl implements Database
>and
> abstract class TransactionContext (for the generic part)
> class TransactionContextImpl extends TransactionContext (db specific
stuff)
>is nice, but not really useful right
ooked yesterday at distributed cache at
>http://jakarta.apache.org/turbine/jcs/
>and I wonder what should be changed in Castor JDO
>except adding invalidate and Cache factory in order to
>use it.
>
>Ilia
>--- Ned Wolpert <[EMAIL PROTECTED]> wrote:
>> -BEGIN PGP SIGNED M
D]
>Subject: Re: [castor-dev] Strategy Proposal (repost - was: Castor JDO
Status)
>
>-BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>> From: "Thomas Yip" <[EMAIL PROTECTED]>
>> Date: Mon, 29 Apr 2002 18:28:16 -0700
>>
>> For example, should d
oupled code has been
>holding you back as much as it is helping you. Until that moment, no
>amount of cajoling or complaining will help the person to that place of
>understanding..
>
>This is made worse by the fact that a visit to Avalon or another user of
>Component Oriented Progr
o: [EMAIL PROTECTED]
>Subject: Re: [castor-dev] Strategy Proposal (repost - was: Castor JDO
Status)
>
>So, can you add this method
>String FieldMolder::getName()
>{
> return _fieldName;
>}
>
>Or maybe you have another idea how to implement query
>by example.
>
>Ilia
>
I think you should just start from a much smaller class
(one or two fields), and identify which field(s) causes the
problem.
Thomas
-Original Message-
>From: Jamal Jackson [mailto:[EMAIL PROTECTED]]
>Sent: Friday, April 26, 2002 1:33 PM
>To: [EMAIL PROTECTED]
>Subject: [castor-dev] L
at areas of the code need to be addressed to solve this.
>d) possible approches
>
>Thomas, what do you think ?
>
>Werner
>
>Thomas Yip wrote:
>
>> I second Bruce proposal to put those information
>> on the bugzilla.
>>
>> Thomas
>>
>> >
I second Bruce proposal to put those information
on the bugzilla.
Thomas
>That is *exactly* why I suggested putting all this stuff into
>Bugzilla. It's really the only true living artifact on the web site.
>The web site itself does not get updated very often because it
>requires interventio
>the identity of a class (aka "the FK as part of a PK problem").
>This was identified as a high priority feature
>over a year ago. Had there been better documentation and a
>clear understanding that no work was taking
>place on this feature I would have had a go at fixing this problem
We
Matthew,
I understand your concern. However, the fact is I reviewed many
patches and gave comments to most of them in the past.
If you believe I am the one who not letting good patch come in,
feel free to grab them and apply it. Or even start another one
base on all current patch.
As I already
share it with anyone
>who is interested
with it. Thomas, would u mind to share your
>plan solution
with me so that I can digest how different is my
>solution and
probably adjust it closer to what u have in mind.
>
>thanks.
>
>Regards,
>Low
>-Original Mess
Thank you very much Vince,
Several people had proposed cache clearing in the last two years,
however, none of them would really work.
(To be very honest, I think there are more issues generated
than it would solves, by adhoc attempts)
While I am impressed to see that you even take care of the r
Hi Todd,
The javadoc is updated to the cvs. It will be pull to the website in next
release.
>I only complained about the lack of documentation. Once I have a better
>understanding of how everything works, I will attempt to contribute to the
>docs.
I was only trying to ask for test case. I d
Thierry,
We had several issues with Access, and it is not a supported database.
I notice that you only made changes to SQLEngine.SQLQuery.
Does it means that the load() method of SQLEngine doesn't have
the same problem?
If it is true, I suspect there is a simpler way to fixes the problem.
You
Can you
try it without using PoolMan, and let me know the result?
Thomas
-Original Message-
>From: Timothy Ruppert
[mailto:[EMAIL PROTECTED]]
>Sent: Thursday, February 14, 2002 12:56
PM
>To: [EMAIL PROTECTED]
>Subject: [castor-dev] RE: transaction
hangs
>
>discrimiator field, but it works without object relloading
>and there is mo need for outer joins.
>Do you think this way passable ?
>
>-Ursprüngliche Nachricht-
>Von: Thomas Yip [mailto:[EMAIL PROTECTED]]
>Gesendet: Donnerstag, 14. Februar 2002 19:43
>An: [EMAIL PROTECTED
I think you can setAutoStore( true ) before you start the transaction,
and Castor will transverse the tree for you.
There are bugs reported about that setAutoStore( true ) doesn't work.
However, for each report that I actually looked deep into it, it turned
out to be some other problem, like use
The 0.8.11 way of doing polymorphism is rather a dangerous.
It does not always work. It depends on the order of the object being loaded.
Because of that, it shouldn't be put back.
On the other hand, the right way to do it is done it in lower layer.
Basically, having the SQLEngine to attempt to
Could you try to have an attribute
for your collection fields and see if it work for you.
Thomas
-Original Message-
>From: Todd V. Jonker [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, February 12, 2002 5:18 PM
>To: [EMAIL PROTECTED]
>Subject: [castor-dev] 0.9.3.9 collection incompatibi
Hi Glenn,
Thank you for your persistence.
I would really rather to have a test case for each patch I commit.
If patch writer don't do a test, I would do it myself, even if it means
the latency takes very long. A test case would ensure the quality
of a patch. But even more important, ensure other
id something wrong.
>If anyone could help me further to find out what I did wrong or explain why
>it is working only with the solutions described above, I would be very
>thankful.
>
>Kind regards,
>
>Lothar
>
>
>
>-Ursprüngliche Nachricht-
>Von: Thomas Yip [m
Well, we have no code to handle such situation.
I think you can throws RuntimeException is a good idea for now,
until we figure out that we should actually do something.
However, I see it as very low priority.
Thomas
-Original Message-
>From: Alan Cabrera [mailto:[EMAIL PROTECTED]]
>S
Hum… maybe
I missed an openEJB concerns then.
Can you
tell me why the following doesn’t work for you?
OpenEJBInstanceFactoryAndCallBack
icb
= new OpenEJBInstanceFactoryAndCallBack
icb( … );
JDO jdo =
new JDO();
jdo.setInstanceFactory(
icb );
jdo.setCallbackInterceptor(
i
Well, I took a deeper note. And, I found no problem.
Here what the test case test, with cache set to none.
create person1
commit tx
begin tx
load person1
new groupA
new groupB
new person2
links person1 to groupA (both way)
links person2 to groupA and groupB (both way)
commit
I concluded it is
set). But the permissions table contains
>the permissions
with autogenerated ids (different from the ones i
>had given the
permissions).
>
>So, in the end I still have to create the permissions using
db.create( permission ).
>
>Bert.
>- Original Message -
>F
>been
>> > updated? In other words, how many people are really contributing
towards
>JDO ? If I
>> > remember some past thread on castor-dev correctly, Assaf, for example,
>has left the
>> > project.
>>
>> Werner,
>>
>> Yes, you're corr
creation in
ClassMolder
>
>Gotcha. InstanceFactory sound good?
>
>I'll double check the OpenEJB side to make sure that it's safe to remove
>those methods.
>
>Alan
>
>-Original Message-
>From: Thomas Yip [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, Janua
eat piece of software and I'd love to see it
>give commercial products such as Top Link a run for their money ;-). In my
>experience a public statement of the direction for a product adds a real
>momentum that would otherwise be missing. What do you/others think?
>
>Thanks,
&g
>a) No new features will be accepted on the JDO side of things for the 0.9.4
>release.
If an user send us a feature patch, we would consider it individually.
If it is good quality (not a quick hack) and test cases included,
we would commit it anytime, as long as will find time to review
the pa
I don't think we have timeframe for 0.9.4 yet.
But, unless 0.9.4 release very late, I would guess there would
have no major feature from now to 0.9.4 on the JDO side.
Sorry, we're lacking of resource.
Thomas
-Original Message-
>From: Werner Guttmann [mailto:[EMAIL PROTECTED]]
>Sent:
r ?
>IMHO,
Castor-JDO's are moving too slow now and this is not
>good for the
Castor-JDO future.
>
>Regards,
>Low
>-Original Message-
>>From: Thomas Yip [mailto:[EMAIL PROTECTED]]
>>Sent: Friday, January 11, 2002 3:51
>>To: [EMAIL
in using it, and I
would like to know if we should consider a migration to another solution.
>
>I'm definitely not trying to be pushy, but it would help a
lot for decision making purposes to know what's happening, and what the plans
are for the JDO code.
>-Original Message-
Is the relationship a bi-directional relationship.
Otherwise, make sure it is.
Thomas
-Original Message-
>From: Chris Williams [mailto:[EMAIL PROTECTED]]
>Sent: Monday, January 07, 2002 9:15 PM
>To: [EMAIL PROTECTED]
>Subject: [castor-dev] Composite Object Caching
>
>Our team is work
based on identity and build them only if needed?
>
>-Original Message-
>From: Thomas Yip [mailto:[EMAIL PROTECTED]]
>Sent: Friday, January 04, 2002 4:11 PM
>To: [EMAIL PROTECTED]
>Subject: Re: [castor-dev] Does caching improve read performance?
>
>
>
>OQLQuery al
Array is not supported by Castor JDO.
Thomas
-Original Message-
>From: Gerhard Hipfinger [mailto:[EMAIL PROTECTED]]
>Sent: Friday, December 21, 2001 3:41 PM
>To: [EMAIL PROTECTED]
>Subject: [castor-dev] JDO: mapping of array collections
>
>Hi!
>
>I got the following exception, when I
I don't think we are developing on DTX. The code is there waiting for
somebody to pick it up.
Happy new year.
Thomas
-Original Message-
>From: Mohamed Idrees [mailto:[EMAIL PROTECTED]]
>Sent: Friday, December 28, 2001 7:54 PM
>To: [EMAIL PROTECTED]
>Subject: [castor-dev] Example of
See inline.
-Original Message-
>From: Alex Grivnin [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, January 02, 2002 7:50 AM
>To: [EMAIL PROTECTED]
>Subject: [castor-dev] Jdo and LDAP
>
>Hello,
>
>On the list, I found a post from Thomas Yip about JDO's data st
OQLQuery always goes to the database, because there is no easy way to tell
if all rows interested visible to current transaction are already in cache.
For simply data object model, which has no relationship, it is expected to
have similar timing.
Thomas
-Original Message-
>From: Jack
No
-Original Message-
>From: Agarwal, Piyush [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, January 03, 2002 7:35 AM
>To: [EMAIL PROTECTED]
>Subject: [castor-dev] Inheritance - Map two classes to One table
>
>
>Is it possible to map two classes to one table.
>( i.e. Super and the Sub Class
See inline.
-Original Message-
>From: Agarwal, Piyush [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, January 03, 2002 1:13 PM
>To: [EMAIL PROTECTED]
>Subject: [castor-dev] Inheritance Problem
>
>Hi,
>I have a case in which there is a superclass PROD and 2 subclasses COMPUTER
>and TELEVISION
What you
need is to specify a key generator in the mapping.
http://castor.exolab.org/key-generator.html
Thomas
-Original Message-
>From: Jean-Noël WALLEZ
[mailto:[EMAIL PROTECTED]]
>Sent: Friday, January 04, 2002 7:02 AM
>To: [EMAIL PROTECTED]
>Subject:
It is probably because of the empty string that causes problem with the
dirty check.
Does Oracle changed it behavior on empty string comparison in 8.1.7?
Could you try and let me know if using add the attribute dirty="ignore" into
the field mapping?
Thomas
-Original Message-
>From: l
Thank Victor,
I confess that I missed the mail. I will review it when I get a chance.
Thank,
Thomas
-Original Message-
>From: Victor Hadianto [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, December 18, 2001 5:23 PM
>To: [EMAIL PROTECTED]
>Subject: [castor-dev] patch (enable direct sql
It sounds like a bug. Will have a look into it when I get a chance.
Thank for reporting.
Thomas
-Original Message-
>From: lars.gersmann [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, December 19, 2001 8:13 AM
>To: [EMAIL PROTECTED]
>Subject: [castor-dev] again lazy & depend behaviour
Castor JDO requires a relationship to be bidirectional.
Not a very nice limitation, but...
Thomas
-Original Message-
>From: John Wang [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, December 20, 2001 2:37 PM
>To: [EMAIL PROTECTED]
>Subject: Re: [castor-dev] foreign key assignment for dep
Title: Why it is RelationCollection?
Well, the problem
can be looked at different way.
First,
Castor architecture requires B to be loaded before it can be deleted.
Second, it
is recommended that an identity should have no business meaning.
The two
points together making that
>Maybe this is a bug with cache/Timestampable?
>Clovis
>Thomas Yip wrote:
>If you think your scenario is not among the existing tests,
please update the tests to include it and send us the "diff -u".
>I will take a look at your problem if you do.
>Thomas
&
Thank for the reminder. I did notice your patch. I would review it when I
get a chance.
Thomas
-Original Message-
>From: Matthew Baird [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, December 18, 2001 1:53 PM
>To: [EMAIL PROTECTED]
>Subject: Re: [castor-dev] patch: oracle and buildTableAli
>I haven't look at this (yet), but what is the failure that occurs when
>its redefined? Object is store multiple times in the hashmap?
>
>General question; Castor needs to support jdk1.1 right? Is that one
>reason vector is used? (Beyond if synchronization is needed there)
Castor JDO doesn't s
You need to update() an object before it can be used in a long transaction.
If you don't do it, Castor JDO will treat it as "transparence".
Also, you need implements Timestampable.
Also, I think some of your other problems can be fixed by using the cvs
version.
Thomas
>db.begin();
>
First, thank you for sharing your finding.
However, there are quite a few critics to Castor JDO, in my opinion is only
a personal programming styles. Also, some inaccurate information.
Thomas
--
"In your document, you wrote "Castor only implements Eager relationship". It
is not true.
gt;
>> hi again,
>>
>> --On Dienstag, 4. Dezember 2001 14:51 -0800 Thomas Yip <[EMAIL PROTECTED]>
>> wrote:
>>> Your version seems to be very old. Please update to the cvs version.
>> i did this, but the error apears again:
>>
>> java.lang.Nu
Object created thru Castor will be inserted into database right the way.
If you're creating an object and loading it from different transaction
concurrently (thru castor or direct jdbc), locking is expected. Typical
behavior is that a database locks each row inserted into a table, until the
trans
Thank for the reminder. Almost forgot about it.
Thomas
-Original Message-
>From: Dmitri Colebatch [mailto:[EMAIL PROTECTED]]
>Sent: Sunday, December 02, 2001 4:41 PM
>To: [EMAIL PROTECTED]
>Subject: Re: [castor-dev] Castor 0.9.4 and Next Release information
>
>Hi,
>
>I missed this me
The patch is committed.
Thank Todd Rader and Dominik for your bugs reporting and patching.
Thomas
-Original Message-
>From: Dominik Baranowski [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, November 27, 2001 4:18 PM
>To: [EMAIL PROTECTED]
>Subject: Re: [castor-dev] another bug fix(how
Title: bug in CVS version
Committed into the cvs.
Thank a lot for your patient.
Thomas
-Original Message-
>From: Thomas Yip
[mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, November 28, 2001
12:57 AM
>To: [EMAIL PROTECTED]
>Subject: Re: [cas
Added.
Thomas
-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Markus Fritz
>Sent: Friday, November 09, 2001 8:01 AM
>To: [EMAIL PROTECTED]
>Subject: [castor-dev] BugFix: Timestamp type support
>
>Hi,
>
>i need Timestamp type fields and realized that t
The bug is fixed. And, tests are added to avoid reoccurrence in the future.
Thank for reporting.
For faster response in the future, please remember to make us test cases
base on the existing tests and send us the diff.
Thomas
-Original Message-
>From: Tim Fox [mailto:[EMAIL PROTECTED
Any error
happens during commit() will cause the transaction to be rollback()
automatically. It is expected.
Your catch
clause call rollback() again, after it was done automatically. It is why TransactionNotInProgressException is
thrown.
It is not
a Castor problem.
You patch is applied. Because there are a few strange character in the
original files, and my patch program doesn't really like it. So, I copy and
made the changes by hands. Please double check.
And, I also updated the cvs.xml doc.
Thank you very your contribution.
-Original Message-
Ok. I only updated one of the two. I missed another
On the other hand, the format we prefer is
cvs diff -u
against the most recent cvs version, not release version.
Thomas
-Original Message-
>From: Todd V. Jonker [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, November 29, 2001 1:03
Title: bug in CVS version
Soon!
Thomas
-Original Message-
>From: Jakob Braeuchi
[mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, November 27, 2001 11:18
PM
>To: [EMAIL PROTECTED]
>Subject: Re: [castor-dev] bug in CVS
version
>
>hi brett,
>
>i'm happy i'm not
Title: what does this mean?
First,
make sure you use cvs version.
Second, please
check to make sure that your scenario wasn’t existed in test cases first. I
didn’t read the whole thread, but I am pretty sure some tests do test that: “cannot use related objects which use a
key-genera
Thank Dominik,
Your insight helped me pinpointed the bug.
Also, thanks Ned Wolpert for reporting the problem a week ago.
Please try the cvs and let me know if the changes fixed the problem you guys
reported.
Thomas
-Original Message-
>From: Dominik Baranowski [mailto:[EMAIL PROTEC
Ok. It makes sense.
But in this case, it depends on how jBoss recycle out-of-space object.
It would be the containers or the integration code's responsibility to make
Castor aware of the object returned by pm.findByPrimaryKey(),
if what is returned is not come from Castor in the same transaction
See inline.
-Original Message-
>From: Jacek Kruszelnicki [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, 22 November 2001 9:14 a.m.
>To: [EMAIL PROTECTED]
>Subject: Re: [castor-dev] Castor behaves differently within JBoss
>
>
>OK, for now I set autostore to false in the MBean configuration.
e a nullpointerexception. If the fk-field is not
>null (i.e. it's a value that references the other table), the code works
>perfectly. It's the function QueryResults.hasMore() that nullpointers.
>
>Hopefully i've made the problem clear now... any solutions?
>
>Thank
Ned,
I tried the test case you submitted. I even set thread count to 50.
However, I don't have the problem you're having.
Would the problem related to Poolman?
I use Oracle (without Poolman) to test your test case.
Thomas
-Original Message-
>From: [EMAIL PROTECTED]
[mailto:[EMAIL
Ned,
I tried the test case you submitted. I even set thread count to 50.
However, I don't have the problem you're having.
Would the problem related to Poolman?
I use Oracle (without Poolman) to test your test case.
Thomas
-Original Message-
>From: [EMAIL PROTECTED]
[mailto:[EMAIL
Jacek,
I am not familiar with jBoss at all.
Give the cvs version a try, if you aren't using it.
Thomas
-Original Message-
>From: Jacek Kruszelnicki [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, November 15, 2001 2:52 PM
>To: [EMAIL PROTECTED]
>Subject: Re: [castor-dev] Reference to an
Thank you for reporting. I replace the private modifier to default. It
should compile in JDK1.2 now.
It probably indicates not many people are using 1.2? Is it true?
Thomas
-Original Message-
>From: BEDNARIK,LASLO (HP-Germany,ex1) [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, Novembe
--
> B C E F
>
>B & C inherit from A, E & F inherit from D, an association 1-N exist
>between
>A & D, I map all classes into a table (6 tables).
>
>I'm wrong with the Castor mechanism ?
>
>
>-Original Message-
>>Date: Thu, 8 Nov
-Original Message-
>From: Thomas Yip [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, November 14, 2001 12:03 PM
>To: [EMAIL PROTECTED]
>Subject: Re: [castor-dev] Multi-threading problems, please help
>
>
>Ned,
>
>I took a note on the problem you reported. Howeve
The
problem was fixed to the cvs, I believe.
Thomas
-Original Message-
>From: Frédéric Augé
[mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, November 14, 2001 6:39
AM
>To: [EMAIL PROTECTED]
>Subject: Re: [castor-dev] Error with
mapping ?
>
>Hi,
>
>I had the sam
Ned,
I took a note on the problem you reported. However, I don't have time take a
deeper note right the way. I am sorry.
Thomas
-Original Message-
>From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Ned Wolpert
>Sent: Wednesday, November 14, 2001 8:26 AM
>To: [EMAIL PROTE
Title: using specific array types with lazy loading
You can
only use java.util.Collection for lazy loading.
Thomas
-Original Message-
>From: Brett Porter
[mailto:[EMAIL PROTECTED]]
>Sent: Thursday, November 08, 2001 2:35
PM
>To: [EMAIL PROTECTED]
>Subject: [cas
Unidirectional relationship is not support.
Thomas
-Original Message-
>From: Dieter Cailliau [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, November 08, 2001 1:49 AM
>To: [EMAIL PROTECTED]
>Subject: [castor-dev] what is wrong with not mapping one side of
many-to-many?
>
>i'm trying to m
The jdoLoad() behavior is deprecated. The original support of polymorphic
method is removed.
Please search the mail archive.
Thomas
-Original Message-
>From: Gollot [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, November 08, 2001 6:20 AM
>To: [EMAIL PROTECTED]
>Subject: [castor-dev] Clas
It would
be definitely a great contribution, if somebody willing to move all error messages
back to the messages.properties. It is where they should go. Thank ahead! J
Thomas
-Original Message-
>From: Vijay Raghavendra
[mailto:[EMAIL PROTECTED]]
>Sent: Wednesd
It probably a newly reported bug.
Thank for reporting.
Thomas
-Original Message-
>From: Dieter Cailliau [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, November 08, 2001 7:52 AM
>To: [EMAIL PROTECTED]
>Subject: [castor-dev] lazy="true" results in exception
>
>I have an applicatoin that w
Borries,
I think you should put "collection" in the mapping instead of vector for
your case.
Thomas
>direct="true" collection="collection">
-Original Message-
>From: Matthew Baird [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, November 08, 2001 12:55 PM
>To: [EMAIL PROTECTED]
>Subje
Yes, the rule on introspection is restricted, to correct a default values
bugs.
Change the type to collection="collection" should solve your problem.
Thomas
-Original Message-
>From: Matthew Baird [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, October 30, 2001 4:56 PM
>To: [EMAIL PROTEC
Thank Low,
Your patch is committed. Thank again!
Thomas
-Original Message-
>From: Low Heng Sin [mailto:[EMAIL PROTECTED]]
>Sent: Friday, October 19, 2001 10:16 PM
>To: [EMAIL PROTECTED]
>Subject: [castor-dev] Patch: SQL Function pass through in Order By Clause
>
>Hi all,
>
>I have
Hi Glenn,
It is on my todo list. I was working on some other bugs fixing last week,
didn't have chance to review your yet.
Thank you for your report and patch.
Thomas
-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Glenn Nielsen
>Sent: Friday, Octob
>-Naveen
>
>
>-----Original Message-
>From: Thomas Yip [mailto:[EMAIL PROTECTED]]
>Sent: Monday, October 22, 2001 7:32 PM
>To: [EMAIL PROTECTED]
>Subject: Re: [castor-dev] Potential bug fix for 1:1 relationship updates
>in long transactions
>
>
>
>D
See inline.
-Original Message-
>From: Keith Chew [mailto:[EMAIL PROTECTED]]
>Sent: Monday, October 22, 2001 7:21 PM
>To: [EMAIL PROTECTED]
>Subject: Re: [castor-dev] Long Transaction
>
>Hi
>
>Ok, there are 2 ways to do this. The hard way is to simulate a short
>transaction for a long tra
fix for 1:1 relationship updates in
long transactions
>
>Thomas,
>
>I had submitted a test earlier. Please look at the following link
>http://www.mail-archive.com/castor-dev@exolab.org/msg00768.html
>
>Thanks!
>
>-Naveen
>
>-Original Message-
>From: Thomas Yip [mai
er,
you found that your watch is still working.
Tell me, is the watch broken or not?
Thomas
> -Original Message-
>> From: Thomas Yip [mailto:[EMAIL PROTECTED]]
>> Sent: Sunday, 21 October 2001 12:13 p.m.
>> To: [EMAIL PROTECTED]
>> Subject: Re: [castor-
allows the separate
>transaction scenario.
>
>Regards
>Keith C
>
>
>> -Original Message-
>> From: Thomas Yip [mailto:[EMAIL PROTECTED]]
>> Sent: Sunday, 21 October 2001 8:07 a.m.
>> To: [EMAIL PROTECTED]
>> Subject: Re: [castor-dev] Found JDO
I believe the problem solved a while ago. It is in the CVS.
If you don't uses autoStore(), it is user responsibility to create object in
sequence.
If autoStore() is used, Castor walked the tree, and marked object to be
created.
Then, it creates object that do not depends on other ids first. And,
I found only one-many relationship in the mapping you provided!
Thomas
-Original Message-
>From: Matthew Baird [mailto:[EMAIL PROTECTED]]
>Sent: Friday, October 19, 2001 6:21 PM
>To: [EMAIL PROTECTED]
>Subject: [castor-dev] many to many
>
>I've reached the conclusion that the many-to
n (one by Castor, antoher by the "external"). Although in
theory it should work, providing that the same row will NOT modified by two
connections in the same transaction, but it is not case in reality for most
TransactionManager.
Thomas
>thank you.
>
>Regards
>-------
It is not implemented, as far as I know.
Thomas
-Original Message-
>From: Jakob Braeuchi [mailto:[EMAIL PROTECTED]]
>Sent: Monday, October 15, 2001 11:35 AM
>To: [EMAIL PROTECTED]
>Subject: [castor-dev] Read only fields ?
>
>hi,
>
>is anybody working on read-only fields (in the code
It's replaced by
org.exolab.castor.persist.LockEngine
Thomas
-Original Message-
>From: Jakob Braeuchi [mailto:[EMAIL PROTECTED]]
>Sent: Monday, October 15, 2001 11:54 AM
>To: [EMAIL PROTECTED]
>Subject: [castor-dev] org.exolab.castor.persist.CacheEngine
>
>hi,
>
>the docu mentions
1 - 100 of 174 matches
Mail list logo
