che.org
Subject: Re: Best Practices Question
On 22/04/2009, at 6:40 AM, Ylan Segal wrote:
> In a web app where each session has a DataContext, do I need to
> worry about data caching in different DataContexts?
I'd like to add just one further point. It is a common design pattern
On 22/04/2009, at 6:40 AM, Ylan Segal wrote:
In a web app where each session has a DataContext, do I need to
worry about data caching in different DataContexts?
I'd like to add just one further point. It is a common design pattern
to create one read-only 'shared' context which is used to f
Andrus, Michael,
Thanks for your answers, they were very helpful.
On Apr 21, 2009, at 2:00 PM, Michael Gentry wrote:
On Tue, Apr 21, 2009 at 4:40 PM, Ylan Segal
wrote:
Ok. That makes sense. I can see that for a web application you
would want to
have each user manipulate data on it's own,
On Tue, Apr 21, 2009 at 4:40 PM, Ylan Segal wrote:
> Ok. That makes sense. I can see that for a web application you would want to
> have each user manipulate data on it's own, without affecting what other
> users are doing. As far as junit test cases go, I can just create a new
> DataContext witho
On Apr 21, 2009, at 11:40 PM, Ylan Segal wrote:
In a web app where each session has a DataContext, do I need to
worry about data caching in different DataContexts? I don't know if
that is clear, so let me explain. Suppose we are talking about a pet
store. User A and B are both separately
i
On Apr 21, 2009, at 12:31 PM, Robert Zeigler wrote:
An object context is a virtual "sandbox" for making changes to the
stored state.
This isn't a perfect analogy because there's no notion of a
"history" of commits, but...
if you're familiar with SVN or any other source control management
sy
An object context is a virtual "sandbox" for making changes to the
stored state.
This isn't a perfect analogy because there's no notion of a "history"
of commits, but...
if you're familiar with SVN or any other source control management
system, you can kinda think of an ObjectContext like you
Andrus,
What you describes is very similar to the pet-store example, and also
seems very reasonable to me.
I guess my only problem now is to learn a bit more about
ObjectContext. I don't really know what I need there, since I don't
really understand what an ObjectContext represents. In th
Let me also point that what I am suggesting is exactly the same as
what Michael did. The difference lies in the presence of an IoC
container and all the data access methods moved out of DataObjects to
the "DAO services".
In some applications picking one or the other style makes no
differe
Yeah, it depends greatly on the general app architecture and usage
patterns... IIRC the petstore example was taken from Spring and
rewritten with Cayenne, so it may have some of the Spring-induced
artifacts (don't remember all the details).
The pattern I am personally following lately in th
I'm not familiar with the Pet Store example, so I'm not sure what was
meant by it not being a best practices example. Also, people have
many different ideas of what they think a best practice is, so it can
vary greatly.
My typical usage is to put my custom business logic in the
Cayenne-generated
Been meaning to implement a runtime "multiple configs merge"
algorithm in Cayenne for some time. I think there may even be a Jira
for that somewhere. Conceptually this is a valuable addition as it
allows seamless modular packaging.
As for the workaround that does not involve manual merging,
Hello Chris,
We have the same configuration here.
We put cayenne.xml in our/class/path/ in Package B.
From Package A, we load package B's cayenne.xml :
DefaultConfiguration conf = new DefaultConfiguration();
conf.addClassPath("our/class/path");
Configuration.initializeSharedConfiguration(conf)
13 matches
Mail list logo
