Re: Alias syntax

Generating aliases is definitely a bad idea, as when we use the
alias-less methods for eq(), gt(), etc. we would have to tell back what
alias has been assigned to the table we are dealing with... this would
complicate things.

So I implemented the as(alias) method, that apply on last added table.
The only caveat is if you want to use the same table several times in a
query, you must give an alias each time you use this table. No a big
deal I think...

I also removed all depracated methods from SQuery. This breaks existing
code...

As usual, we can always revert if necessary.

Franck


Le mercredi 25 mars 2009 à 12:25 +0100, Franck Routier a écrit :
> One caveat is that then the table will first be added with its default
> alias, which might be used already...
> So maybe we should really generate alias as firstletter
> +tables.size()...
> 
> Le mercredi 25 mars 2009 à 12:09 +0100, Franck Routier a écrit :
> > Hi,
> > 
> > I like the setAlias() solution, that changes the alias for the last
> > added table.
> > 
> > I also suggest to call it simply as().
> > 
> > SQuery<Employee> subQ2 = new
> > SQuery<Employee>(Employee.EMPLOYEE).as("emp")
> > .join("emp", Employee.MANAGER, SSelectMode.SNONE).as("manager")
> > .join("manager", Employee.DEPARTMENT)
> > .eq(Department.MISSION, "Count Pennies")
> > .descending("emp", Employee.SALARY);
> > 
> > What do you think of this ?
> > 
> > 
> > Le mercredi 25 mars 2009 à 20:55 +1000, [email protected] a
> écrit :
> > > Hello Franck,
> > > 
> > > I was just updating the white paper with
> > > 
> > > SQuery<Employee> subQ2 = new
> > > SQuery<Employee>(Employee.EMPLOYEE).setAlias("emp")
> > > .join("manager", "emp", Employee.MANAGER, SSelectMode.SNONE)
> > > .join("dept", "manager", Employee.DEPARTMENT)
> > > .eq("dept", Department.MISSION, "Count Pennies")
> > > .descending("emp", Employee.SALARY);
> > > 
> > > I note that we should not really need to specify the "dept" alias
> at
> > > all. But it cannot be removed from the second join statement
> because
> > > manager needs to be specified. If the parameter order did not have
> two
> > > strings next to each other that could be achieved. 
> > > 
> > > I am wondering whether
> > > .join("dept", Employee.DEPARTMENT, "manager")
> > > is clearer. And thus
> > > .join(Employee.DEPARTMENT, "manager")
> > > Not sure. 
> > > 
> > > But then we end up with far to many polymorphic methods -- I wish
> Java
> > > had keyword optional arguments!
> > > (Also, the join parameter names do not make it clear which is
> which.
> > > Maybe newAlias and previousAlias would be better?)
> > > 
> > > Maybe
> > > .join(...).setSelectMode(SNONE)
> > > ie. set* affects the previous SQueryTable (including the main one
> if
> > > at the beginning).
> > > Thus maybe setAlias(), setJoinedAlias()?
> > > 
> > > (Should replace .join with innerJoin everywhere.)
> > > 
> > > (I'd like a good example for the white paper in the test cases,
> > > include leftJoin.)
> > > 
> > > Anthony
> > > 
> > > Dr Anthony Berglas, [email protected] Mobile: +61 4 4838 8874
> > > Just because it is possible to push twigs along the ground with
> ones
> > > nose
> > > does not necessarily mean that is the best way to collect
> firewood.
> > > 
> > > 
> > > 
> > > 
> > > 
> 
> 
> 
> 
> 




------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/SimpleORM/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/SimpleORM/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/