OK. Should we then widen the SSessionI interface?

It's nice to be able to write fully testable code that doesn't depend on the
concrete SSessionJdbc.

But you can't specify a sorting, for example, with the currently supported lazy
retrieval:
getDataSet().getSession().find(Employee.EMPLOYEE, new SFieldScalar[] {
Employee.DEPARTMENT }, SREAD_ONLY, d100q)

And if this sort of thing is deprecated, then will findReference be similarly
deprecated?

Thanks!
--- In SimpleORM@yahoogroups.com, berglas@... wrote:
>
> A good question, and the answer is no.
>
> Suppose one performed a query to
> select Employees in Sales where Salary > 100000 order by Name
>
> What would you expect findReferencing to return? All employees, or just those
queried?
>
> And how sorted? And what use is an unsorted list?
>
> So instead we make the query explicit
>
> List<Employee> employess = new
SQuery(Employee.EMPLOYEE).eq(Employee.DEPARTMENT, d100q)
>
> This makes the semantics clear, is much more flexible, and is hardly any more
typing. (Hibernate is a mess in this area, because it tries to impose the low
level Object Oriented model of associations on the higher level realational
database.)
>
> You can also query the DataSet for all Employees that are in memory, and then
filter that. It can be used while the DataSet is detached from the database.
>
> Regards,
>
> Anthony
>
>
>
>
>
>
> At 09:52 AM 7/07/2009, you wrote:
>
>
> >How do you feel about having a findReferencing method in SRecordInstance,
just like the existing findReference there?
> >
> >That'd make it just as easy to lazily fetch the one-to-many as the
many-to-one relationship.
> >
> >E.g.
> >Already:
> >Department department = employee.findReference(employee.DEPARTMENT);
> >
> >Proposing also:
> >List<Employee> employess = department.findReferencing(employee.DEPARTMENT);
> >
> >Thanks,
> >Josh
> >
> >
>
>
> Spreadsheet Detective,
> Southern Cross Software Queensland Pty Limited
> 54 Gerler Street
> Bardon, Queensland 4065, Australia.
>
> Email: berglas@...
> www.SpreadsheetDetective.com
> Ph: +61 427 830248 (Australian Eastern Standard Time)
>
> "If the model seems correct only because the numbers look right,
> then why build the model in the first place?"
>