Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: Add ActiveRecord support to Cayenne
From: Andrus Adamchik <andrus@objectstyle.org>
In-Reply-To: <B4FC4BB8-16A6-4190-8AE4-2FB0F1243C6C@objectstyle.org>
Date: Thu, 27 Dec 2012 10:47:31 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <2D1E41AB-AE70-4B1A-BD07-BEF975054CCE@objectstyle.org>
References: 
 <CAN-eyachZdvso0fP=KWiST=AfgegbW_T4FjG+F4k8jU5o4q_mQ@mail.gmail.com>
 <CAOUwSGsD2H0UR-cXk_ib4TXGkh_uUSj_zLqxDh=EPLVkx0ozDw@mail.gmail.com>
 <CAA-upzq2hbbsbSBZX0NEnAA==MQrUfE8B+Jg68hzAioo7hBRvg@mail.gmail.com>
 <CAN-eyaeXokjfQmGfz_yy9XRkY5QYS+4uqHkYo3npVv-E-ZD0qQ@mail.gmail.com>
 <13AA4917-A91F-43A2-AF3F-E9A481C70CCE@objectstyle.org>
 <50D74358.8090409@maniatis.org>
 <CAN-eyac0GzFHnY6K7pfEV=tgRfPPAi0_mPTEYCO=7MXG4zp7vg@mail.gmail.com>
 <50DB14C8.2060503@maniatis.org>
 <211B9D42-C0FE-4194-BD05-BFFA61B37E7D@objectstyle.org>
 <50DB2E11.6070209@maniatis.org>
 <4988EEBF-7443-43F0-8DDD-2026D71C2E93@objectstyle.org>
 <1356556437.50730.YahooMailNeo@web122303.mail.ne1.yahoo.com>
 <CAFrHPLHkp201ZWvLmzsqVgfiL5aUZ9ONPNqUy0qeLjFKV89NQg@mail.gmail.com>
 <1356558464.78611.YahooMailNeo@web122306.mail.ne1.yahoo.com>
 <CAN-eyacFQ4h+XPRW6GwKiHktRJYqCXPXosdQGX8wqh_MWJemFA@mail.gmail.com>
 <CAN-eyacU5dTBdxK41DitT1ZvjwE3ZQCpTHngoAYG5wO1qoMGNg@mail.gmail.com>
 <50DBCD7D.2060108@maniatis.org> <B4FC4BB8-16A6-4190
 -8AE4-2FB0F1243C6C@objectstyle.org>
To: user@cayenne.apache.org

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".=20

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 <andrus@objectstyle.org> =
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).=20
>=20
> 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.
>=20
> Andrus
>=20
> [1] =
http://cayenne.apache.org/docs/3.1/cayenne-guide/starting-cayenne.html#web=
apps
>=20
>=20
> On Dec 27, 2012, at 7:24 AM, Aristedes Maniatis <ari@maniatis.org> =
wrote:
>> On 26/12/12 6:48pm, =D0=94=D1=80=D0=BE=D0=B1=D0=B5=D0=BD=D1=8F =
=D0=98=D0=BB=D1=8C=D1=8F 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.
>>=20
>> Let's take:
>>=20
>> a.delete()
>> b.delete()
>> a.commitChanges()
>>=20
>> 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?
>>=20
>> b.newInstance();
>> a.setFriend(b);
>> a.commitChanges();
>>=20
>> Will that work in your API? Do I need to commit b first? What if I =
have a foreign key constraint?
>>=20
>>=20
>> 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:
>>=20
>> ActiveRecord::Base.transaction do
>> b.save
>> a.friend =3D b
>> a.save
>> end
>>=20
>> 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?
>>=20
>>=20
>>=20
>> Ari
>>=20
>>=20
>> --=20
>> -------------------------->
>> Aristedes Maniatis
>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>>=20
>=20
>=20