I think the idea is to combine the new API with existing Cayenne facilities for providing thread-bound ObjectContext based on some custom strategy (e.g. CayenneFilter [1]) and then using the API within a single thread context. And committing via a single static class (instead of committing individual objects).
This is a simplification certainly, and to me this discussion is about establishing whether there is a class of apps that can happily live with such simplification. Andrus [1] http://cayenne.apache.org/docs/3.1/cayenne-guide/starting-cayenne.html#webapps On Dec 27, 2012, at 7:24 AM, Aristedes Maniatis <a...@maniatis.org> wrote: > On 26/12/12 6:48pm, Дробеня Илья wrote: >> This is the best OOP design. And for me need to separate context only when >> we need anvanced features that do not possible in current design. > > Let's take: > > a.delete() > b.delete() > a.commitChanges() > > Are there two separate contexts there so I committed only the 'a' deletion? > Or is there one shared context across the application, so I committed both > deletions? > > b.newInstance(); > a.setFriend(b); > a.commitChanges(); > > Will that work in your API? Do I need to commit b first? What if I have a > foreign key constraint? > > > The idea of the fluent query API (as per Rails) is very attractive. The idea > of hiding Context not as much (to me). In Rails lots of code looks like this: > > ActiveRecord::Base.transaction do > b.save > a.friend = b > a.save > end > > Although a Cayenne context is more than just a transaction, it also solves > the problem that Rails would use a transaction for. How will you do that? > > > > Ari > > > -- > --------------------------> > Aristedes Maniatis > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A >
