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 your working
copy, and the database as trunk.
You make your changes, and then you can either commit those changes,
or you can revert them, exactly analogous to a src commit or revert.
It's also the means through which you'll route your queries.
Robert
On Apr 21, 2009, at 4/211:36 PM , Ylan Segal wrote:
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 the past, for
web applications like the one I am planning now, I have used a DBCP
or similar to get java.sql.Connections that are later used by
objects to perform queries. Of course, this is pretty tedious, and
thus why I am looking at Cayenne.
The documentation suggests that for web applications one DataContext
tied to each user session (say, via a filter) is appropriate. Why do
I need more than one DataContext in my application at all? I could
just create a singleton that gets DataContext to any object (DAO)
that needs it. What is the drawback there?
What about unit testing? How do I provide a DataContext to my tests?
I guess I just need to understand what a DataContext (or
ObjectContext for that matter) is all about.
Thanks for the help,
--
Ylan.
On Apr 21, 2009, at 6:43 AM, Andrus Adamchik wrote:
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 the systems that
have an IoC container (say Spring or Tapestry), is to define one
generic Cayenne "service" that gives access to an ObjectContext
depending on your needs, and a bunch of "DAO services" that
encapsulate specific queries and other data operations, including
cache strategies. This way the frontend code doesn't have to deal
with cache rules and other low level details. This requires some
thought on the design, but at the end scales best in terms of
complexity.
Here is some examples:
interface CayenneService {
// depending on implementation this can return application or
session-level shared context.
// often this is a read-only context...
ObjectContext getSharedContext();
// creates a new context
ObjectContext createNewContext();
}
interface AccountDAO {
List<Account> getActiveAccounts();
List<Account> getNewAccounts();
List<Account> searchAccounts(Stirng searchCriteria);
}
class AccountDAOImpl implements AccountDAO {
// injected
CayenneService cayenneService;
List<Account> getActiveAccounts() {
SelectQuery query = new SelectQuery(Account.class);
query.andQualifier(...);
query.andQualifier(...);
query.setCacheStrategy(...);
query.setCacheGroups(...);
return cayenneSerice. getSharedContext().performQuery(query);
}
}
Andrus
On Apr 21, 2009, at 4:26 PM, Michael Gentry wrote:
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 subclass and to also put my "fetch" type methods
in
there, too (when not creating them in Cayenne Modeler). The more
interesting questions (to me) are what are the usage patterns, etc.
That helps determine how to use the DataContext (or ObjectContext),
how to do data refreshing, etc. One application I did had a single
read-mostly DC that I synchronized access to for all the users (the
queries took a prohibitive amount of time for interactive usage,
so I
cached things in a single DC). Others I used one (or more) DCs per
user's session. Again, it really depends upon what your
requirements
are for data access.
Feel free to ask more questions. Hope that helped just a little.
mrg
On Mon, Apr 20, 2009 at 3:30 PM, Ylan Segal <ylan.se...@gmail.com>
wrote:
Hi Everyone,
I am new to Cayenne. I was looking at the examples in the wiki,
especially
at the pet store:
http://cwiki.apache.org/CAY/cayenne-petstore.html
So far, I like what I see. The above page does mention that the
pet store
example "... definitely needs a rewrite and DB redesign before we
can call
it Cayenne Best Practices Demo."
Why isn't it a best practice? Because of the DB design or because
of how
Cayenne classes are used? The overall app design (one domain
package, one
DAO package, one presentation package) seems reasonable to me. I
would be
designing a DB schema from scratch for a web application
(probably with
struts), and I am thinking of following the example pattern,
assuming that
pattern is not what needs rewriting! Can anyone suggest best
practices for
this type of situation? I am looking for more of a "what packages
should we
have" discussion rather than a "this is how you save an object to
the
database" discussion.
I hope this makes sense.
--
Ylan Segal
ylan.se...@gmail.com
