Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: domain of jbraeuchi@gmx.ch designates
 213.165.64.20 as permitted sender)
Message-ID: <415302E5.1060607@gmx.ch>
Date: Thu, 23 Sep 2004 19:07:49 +0200
From: Jakob Braeuchi <jbraeuchi@gmx.ch>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT;
 rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: Phil Warrick <philip.warrick@mcgill.ca>
CC: OJB Developers List <ojb-dev@db.apache.org>
Subject: Re: OJB Alias / UserAlias
References: <4151D94D.3070609@gmx.ch> <4152503A.7070501@mcgill.ca>
In-Reply-To: <4152503A.7070501@mcgill.ca>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi phil,


Phil Warrick schrieb:

> Hi Jakob,
> 
>> you are the alias specialist, so i'm contacting you directly.
>>
>> i would like to clean up alias handling and was thinking about holding 
>> UserAlias only to get rid of m_alias and m_aliasPath instvars. 
>> whenever i use setAlias(String) or setAlias(String,String) i'd like to 
>> create a UserAlias. this is imo no problem in SelectionCriteria, 
>> because we have the attribute there. But what do i do in Criteria ? 
>> create a UserAlias with name only ? Criteria#getUserAlias(Object 
>> attribute) picks the UserAlias if available so it would get the 
>> 'empty' UserAlias instead of building a new one.
>>
>> another question is whether we really need a UserAlias on 
>> SelectionCriteria level. isn't it sufficient to have on UserAlias on 
>> Criteria level and simply add the SelectionCriteria attributes ?
> 
> 
> It's true that it is redundant to have instvars of m_alias and 
> m_aliasPath at both the Criteria and SelectionCriteria levels.  There 
> can only be one UserAlias per Criteria, no matter how many 

should this alias hold the attributes of it's SelectionCriteria ?

> SelectionCriteria are associated with it.  So I would agree to put it at 
> the Criteria level only.  There are calls to UserAlias methods of 
> SelectionCriteria object (e.g. SqlQueryStatement#appendSQLClause(...)) 
> so perhaps these methods should remain at the SelectionCriteria level, 
> but delegate their work to their Criteria object.

that's what i'm thinking of.
> 
> Instead of delegating to SelectionCriteria#setAlias(String alias), 
> Criteria#setAlias(String alias) can get the attributes it needs 
> directly, something like:
> 
> // propagate to SelectionCriteria,not to Criteria
> for (int i = 0; i < m_criteria.size(); i++)
> {
>     if (!(m_criteria.elementAt(i) instanceof Criteria))
>     {
>         String attributePath = 
> ((String)((SelectionCriteria)                  
> m_criteria.elementAt(i)).getAttribute()));
>         boolean allPathsAliased = true;
>         m_userAlias = new UserAlias(alias, 
> attributePath,                         allPathsAliased);   
>     }
> }

in this case we create a UserAlias per SelectionCriteria but store only the last 
one !?

> 
> The original assumption behind this method, i.e. that the 
> SelectionCriteria have been added to the Criteria before setAlias is 
> called, still holds.
> 
> Hope this helps,

thanks, but i still need more help ;)

jakob

> 
> Phil
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org