QBE interface

Hello Franck,

I agree that any QBE interface in SimpleORM would want to be a 
separate module, used along the lines that you suggest.

One hard part about QBEs is joins/subselects.  Eg. Employees in 
Department with name like %SALES%.  Or with Manager Name like 
%BROWN%.  It is not uncommon to have user query interfaces that 
include fields from parent records.  But then we need to represent 
reference paths.  Eg. Employee.Manager.Department.Name.

Now, reference paths are also needed to fully implement outer 
Joins.  So worth keeping in mind the similarity.

For now, lets leave QBE go.  (Hibernate does not implement it either.)

Do you think that you might have time to work on the outer joins 
(single level, without reference paths)?  Main task is move join 
condition to ON clause, and add aliases.

Regards,

Anthony


At 07:40 PM 10/09/2008, Franck Routier wrote:
>Hi Anthony,
>
>here are our thoughts about QBE in Simpleorm3:
>
>1) first option is to completly leave this stuff out of Sorm3, as it is
>really something that has to do with UI interacting with sorm3 rather
>than sorm3 stricto sensu. QBE can be done with sorm3 as is.
>
>2) if we want to add QBE capabilities to sorm3, the main problem is to
>agree on a QBE syntax that fits everybody needs.
>We think it could be done this way:
>
>- create a Filter<R extends SRecordMeta> object, that will be a map of
>SFieldScalar/String (or object ?) of the fields belonging to R. This is
>quite similar to a SRecordInstance, but lives outside of a dataset and
>cannot be persited (no isNewRow, etc.). No ambiguity.
>
>- have a applyFilter(SQuery qry) on Filter that would parse the strings
>to add eq(), like() and so on to qry
>
>- propose a default implementation for applyFilter, simply defaulting to
>like for SFieldStrings (maybe only the QBE string contains a % or _),
>and eq() for the other field types
>
>- make filter.applyFilter() overridable or provide hooks if the user
>want to implement more complex QBE synthax (allowing > or < for numeric
>fields, allowing enumerations with ; or | separator, ranges, etc.)
>
>So the typical use would be :
>
>Filter filter = new Filter(recordMeta);
>// user application specific code to populate filter
>// eg uilayer.mapScreenInFilter(filter);
>SQuery qry = new SQuery(SRecordMeta);
>qry = filter.applyFilter(qry);
>ses.begin();
>List res = ses.query(qry);
>...
>ses.commit();
>
>We could also add a constructor to SQuery to take a Filter as an
>argument.
>
>List res = ses.query(new SQuery(filter));
>
>What do you think of it ?
>
>Franck
>

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/