You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2011/01/26 16:35:48 UTC
Inclusion of cayenne-lifecycle in 3.1
You may remember a discussion of the mixin concept. Since then I've integrated the cayenne-mixin module into 2 of my projects and have been gradually migrating various custom-coded solutions to cayenne-mixin. This resulted in a few cool generic features in Cayenne core (lifecycle annotations, DataChannelFilter), as well as a number of new things in the mixin module.
What we ended up with is a neat generic mechanism that I would call "annotations-based lifecycle and workflow management". Mixins (the ability to add special runtime properties to existing objects) are just one aspect of it, and I haven't solved any of the limitations that we discussed before. Nevertheless the new framework is extremely useful for higher level event-driven programming in Cayenne (lower level being managing per-event per-object lifecycle listeners).
It has a few generic concepts - UUID/Referenceable, ChangeSet, and a few defined "event handlers" (or "workflow handlers") for audit management, cache invalidation. Users can create their own business-specific extensions and their own lifecycle annotations (which I am doing actively in my apps).
So I am suggestion to move cayenne-mixin to the main development tree from sandbox (under the name "cayenne-lifecycle") and include it in 3.1 releases as a separate jar. This will allow our users to get the "official" builds of cayenne-lifecycle, and hopefully won't create release scheduling conflicts between the core and lifecycle.
My hope that this meta-programming facility will streamline implementation of many common scenarios for our users.
Comments?
Andrus
Re: Inclusion of cayenne-lifecycle in 3.1
Posted by Andrus Adamchik <an...@objectstyle.org>.
But yeah, even the concept of UUID (a String representation of ObjectId) should be enough to make it a hit (and motivate us to move it to the core).
Andrus
On Jan 27, 2011, at 11:19 AM, Andrus Adamchik wrote:
> The main building blocks (DataChannelFilter and lifecycle annotations) are already in the core. The rest of it is still evolving, so I just feel more comfortable to assign it an "extension" status at this point (maybe implying it can go away, or is supported differently than the core). In the future we may decide to move it to the core.
>
> Andrus
>
>
> On Jan 27, 2011, at 12:53 AM, Aristedes Maniatis wrote:
>> On 27/01/11 2:35 AM, Andrus Adamchik wrote:
>>> So I am suggestion to move cayenne-mixin to the main development tree from sandbox (under the name "cayenne-lifecycle") and include it in 3.1 releases as a separate jar. This will allow our users to get the "official" builds of cayenne-lifecycle, and hopefully won't create release scheduling conflicts between the core and lifecycle.
>>
>> The concepts appear to be extremely useful, but I'm not understanding why they don't just go into the core jar. Is it because they still need extra work? Or do they interfere with the existing lifecycle events in some way?
>>
>> Ari
>>
>>
>> --
>> -------------------------->
>> Aristedes Maniatis
>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
Re: Inclusion of cayenne-lifecycle in 3.1
Posted by Andrus Adamchik <an...@objectstyle.org>.
The main building blocks (DataChannelFilter and lifecycle annotations) are already in the core. The rest of it is still evolving, so I just feel more comfortable to assign it an "extension" status at this point (maybe implying it can go away, or is supported differently than the core). In the future we may decide to move it to the core.
Andrus
On Jan 27, 2011, at 12:53 AM, Aristedes Maniatis wrote:
> On 27/01/11 2:35 AM, Andrus Adamchik wrote:
>> So I am suggestion to move cayenne-mixin to the main development tree from sandbox (under the name "cayenne-lifecycle") and include it in 3.1 releases as a separate jar. This will allow our users to get the "official" builds of cayenne-lifecycle, and hopefully won't create release scheduling conflicts between the core and lifecycle.
>
> The concepts appear to be extremely useful, but I'm not understanding why they don't just go into the core jar. Is it because they still need extra work? Or do they interfere with the existing lifecycle events in some way?
>
> Ari
>
>
> --
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Inclusion of cayenne-lifecycle in 3.1
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 27/01/11 2:35 AM, Andrus Adamchik wrote:
> So I am suggestion to move cayenne-mixin to the main development tree from sandbox (under the name "cayenne-lifecycle") and include it in 3.1 releases as a separate jar. This will allow our users to get the "official" builds of cayenne-lifecycle, and hopefully won't create release scheduling conflicts between the core and lifecycle.
The concepts appear to be extremely useful, but I'm not understanding why they don't just go into the core jar. Is it because they still need extra work? Or do they interfere with the existing lifecycle events in some way?
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Inclusion of cayenne-lifecycle in 3.1
Posted by Ksenia Khailenko <xe...@tut.by>.
The annotations for the lifecycle management seem to be very useful and
attractive feature. It will be great to have them in development tree for
more common use and test of their work(I mean, in development tree there
will be easier to detect some possible weaknesses )
2011/1/26 Andrus Adamchik <an...@objectstyle.org>
> You may remember a discussion of the mixin concept. Since then I've
> integrated the cayenne-mixin module into 2 of my projects and have been
> gradually migrating various custom-coded solutions to cayenne-mixin. This
> resulted in a few cool generic features in Cayenne core (lifecycle
> annotations, DataChannelFilter), as well as a number of new things in the
> mixin module.
>
> What we ended up with is a neat generic mechanism that I would call
> "annotations-based lifecycle and workflow management". Mixins (the ability
> to add special runtime properties to existing objects) are just one aspect
> of it, and I haven't solved any of the limitations that we discussed before.
> Nevertheless the new framework is extremely useful for higher level
> event-driven programming in Cayenne (lower level being managing per-event
> per-object lifecycle listeners).
>
> It has a few generic concepts - UUID/Referenceable, ChangeSet, and a few
> defined "event handlers" (or "workflow handlers") for audit management,
> cache invalidation. Users can create their own business-specific extensions
> and their own lifecycle annotations (which I am doing actively in my apps).
>
> So I am suggestion to move cayenne-mixin to the main development tree from
> sandbox (under the name "cayenne-lifecycle") and include it in 3.1 releases
> as a separate jar. This will allow our users to get the "official" builds of
> cayenne-lifecycle, and hopefully won't create release scheduling conflicts
> between the core and lifecycle.
>
> My hope that this meta-programming facility will streamline implementation
> of many common scenarios for our users.
>
> Comments?
> Andrus
--
Regards, Ksenia Khailenko