Mailing-List: contact commits-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cayenne.apache.org
Date: Thu, 19 Sep 2013 07:38:51 +0000 (UTC)
From: "Andrus Adamchik (JIRA)" <jira@apache.org>
To: commits@cayenne.apache.org
Message-ID: <JIRA.12669401.1379576159703.160559.1379576331575@arcas>
In-Reply-To: <JIRA.12669401.1379576159703@arcas>
References: <JIRA.12669401.1379576159703@arcas>
Subject: [jira] [Updated] (CAY-1872) Easier mapping of default listener
 methods
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CAY-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrus Adamchik updated CAY-1872:
---------------------------------

    Description: 
IIRC a listener method like this doesn't match anything (the actual annotation can be any lifecycle annotation.. the important part is absent entity filter) :

@PrePersist
public void doSomething(T x) { }

We should actually match that based on the "T" type instead. So if T is an Object or DataObject, it should match every entity in the model, if T is a specific entity class, it should match that specific class. So more generally it should match entities that are of type T or any subtype of T

Performance is a consideration... T can be a class or an interface. I can see how we can make this efficient with T being a class. With T being an interface other than DataObject or Persistent, we'll need to analyze all persistent classes in the Model, which can affect performance. I guess we can make a partial implementation initially supporting T as a class and DataObject / Persistent interfaces, and then see how bad is a class hierarchy scan with an arbitrary interface. 

  was:
IIRC a listener method like this doesn't match anything (the actual annotation can be any lifecycle annotation.. the important part is absent entity filter) :

@PrePersist
public void doSomething(T x) { }

We should actually match that based on the "T" type instead. So if T is an Object or DataObject, it should match every entity in the model, if T is a specific entity class, it should match that specific class. So more generally it should match entities that are of type T or any subtype of T

T can be a class or an interface. I can see how we can make this efficient with T being a class. With T being an interface other than DataObject or Persistent, we'll need to analyze all persistent classes in the Model, which can affect performance. I guess we can make a partial implementation initially supporting T as a class and DataObject / Persistent interfaces, and then see how bad is a class hierarchy scan with an arbitrary interface. 

    
> Easier mapping of default listener methods
> ------------------------------------------
>
>                 Key: CAY-1872
>                 URL: https://issues.apache.org/jira/browse/CAY-1872
>             Project: Cayenne
>          Issue Type: Improvement
>            Reporter: Andrus Adamchik
>            Assignee: Andrus Adamchik
>
> IIRC a listener method like this doesn't match anything (the actual annotation can be any lifecycle annotation.. the important part is absent entity filter) :
> @PrePersist
> public void doSomething(T x) { }
> We should actually match that based on the "T" type instead. So if T is an Object or DataObject, it should match every entity in the model, if T is a specific entity class, it should match that specific class. So more generally it should match entities that are of type T or any subtype of T
> Performance is a consideration... T can be a class or an interface. I can see how we can make this efficient with T being a class. With T being an interface other than DataObject or Persistent, we'll need to analyze all persistent classes in the Model, which can affect performance. I guess we can make a partial implementation initially supporting T as a class and DataObject / Persistent interfaces, and then see how bad is a class hierarchy scan with an arbitrary interface. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira