Hey Michael,
that's exatcly the clue we needed. Now it works like a charme.
The only annoying thing is to put the object from context a to context b.
I would prefer something like "detach" object from commit. But that's not
such a clean way like another context...
Wow.,.. that was a hard day.
On 7/31/07, Jan Lendholt <[EMAIL PROTECTED]> wrote:
> Hi Michael, Hi Aristedes,
>
> thank you very much for your help.
>
> But, still I've got a conceptual problem:
>
> I get an object from the "root" DataContext and pass this object to another,
> e.g. method, to use.
> Now the object is already re
Hi Michael, Hi Aristedes,
thank you very much for your help.
But, still I've got a conceptual problem:
I get an object from the "root" DataContext and pass this object to another,
e.g. method, to use.
Now the object is already registered in the "root" context and I would like
to transer it to
On 7/31/07, Jan Lendholt <[EMAIL PROTECTED]> wrote:
> Just one thing: How do we unset/destroy/throw away an unused DataContext /
> ChildContext?
context = null;
That should be all you need.
/dev/mrg
On 31/07/2007, at 11:26 PM, Jan Lendholt wrote:
I created an object via context.newObject(Service.class);
Before I do a context.commitChanges() I check if there are any
input errors in the input fields that should be set to the object.
If we encounter an exception, we abort the creation /
Hey Michael,
thanks for your answer - we just tried out the nested DataContext's and
that's exactly what we needed. This seems to be the solution. And your
documentation-link was already found by one of my developer.
Just one thing: How do we unset/destroy/throw away an unused DataContext /
I should have included this link on nested DataContexts, in case you
want to explore that option:
http://cayenne.apache.org/doc20/nested-datacontexts.html
/dev/mrg
Two options that immediately come to my mind are:
1) Use separate DataContext instances. You could have one DataContext
per window (or even more if it made sense). Creating a DataContext
isn't a very CPU-intensive activity, so you won't incur a large cost
making many of them. Of course, you can
Hey Folks,
another question:
I created an object via context.newObject(Service.class);
Before I do a context.commitChanges() I check if there are any input errors
in the input fields that should be set to the object. If we encounter an
exception, we abort the creation / editing of the current
I just manually unsubscribed Tobias, but for the future reference -
users can unsubscribe themselves without bothering the list or the
admins. Per http://cayenne.apache.org/mailing-lists.html
"To unsubscribe send empty email to [EMAIL PROTECTED]"
Cheers,
Andrus
On Jul 31, 2007, at 12:12
-Ursprüngliche Nachricht-
Von: Andrus Adamchik [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 31. Juli 2007 11:10
An: user@cayenne.apache.org
Betreff: Re: MVN again - now on Dataviews :( !
All code dependencies do have explicit versions in the parent pom
(and maven actually requires ve
All code dependencies do have explicit versions in the parent pom
(and maven actually requires version to be present). But Maven
plugins are considered different beasts and versions are not
required. If omitted, Maven will fetch the latest version. This
caused us grief in the past already,
I hardcoded version of japplication plugin to 2.0.5 - this is the last
version that I personally tested. Try it now.
Thank you. Now it works :).
If the trick of hardcoding versions does it, wouldn't it make more sense to
add version for other dependencies as well? I mean generally with mvn, not
I hardcoded version of japplication plugin to 2.0.5 - this is the
last version that I personally tested. Try it now.
Andrus
On Jul 31, 2007, at 12:20 AM, Ahmed Mohombe wrote:
Hi,
trying to build dataviews with Maven(as described in the readme)
I'm getting the following error :( :
[INF
I guess we should mention in the README that there is a fork.
Andrus
On Jul 31, 2007, at 10:58 AM, Adrian Wiesmann wrote:
Hello all
#1. Will someone check-in submitted patches (so that the trunk to
contain
everything)?
(If yes, how to proceed? )
#2. Will it be possible/allowed to publish
Hello all
> #1. Will someone check-in submitted patches (so that the trunk to contain
> everything)?
> (If yes, how to proceed? )
>
> #2. Will it be possible/allowed to publish (somewhere) a build, e.g.
> dev-version (even if not on
> Apache - e.g.
> a version that might contain some patches). It
16 matches
Mail list logo
