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
> 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.
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 without much consequence. Right?
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
in their browser shopping for a cat. There is only 1 left in
inventory. Both user A and B see that there is one left. User A makes
up his mind first and buys the cat. The changes are committed. In the
DB the inventory correctly has the number of cats at 0. If User B's
DataContext caches the data, it might think that the inventory is
still 1 and also allow User B to buy the cat. Should I worry about
this or is it all taken care of by Cayenne?
Thanks for the answers. In the meantime I have been trying out the
modeler and it seems to do a great job of creating the db schema,
relationship mapping and Java code generation. So far I am very
impressed!
-- Ylan.> 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.sega..mail.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.sega..mail.com >>>>> >>>>> >>>> >>> >> >
-- Ylan Segal ylan.sega..mail.com
This archive was generated by hypermail 2.0.0 : Tue Apr 21 2009 - 16:41:38 EDT