Also FWIW, we are trying to build the same fluent APIs in Cayenne itself, so to me Ilya's proposal is simply reassigning the existing and planned query APIs to objects themselves - a very simple "transposition".
I.e. this proposal is just a different style for what we already have or will have shortly. Certainly not a fundamental change in how the framework operates. Andrus On Dec 27, 2012, at 10:38 AM, Andrus Adamchik <[email protected]> wrote: > 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 <[email protected]> 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 >> > >
