I haven't bothered putting abstract classes on things like SSessionJdbc because
I'm not sure that it is useful. Mocking out the database essentially mocks out
most of your potential problems and I would recommend against it. But it
certainly could be done. (I prefer abstract classes to interfaces because
interfaces can never be extended without breaking the API.)

SSessionI is for a specific purpose (to link data sets to sessions for
references) and should be left alone.

(There are certainly lists of other things to do to SimpleOrm.)

Anthony

At 01:20 PM 7/07/2009, you wrote:


>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 <mailto:SimpleORM%40yahoogroups.com>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?"
>>
>
>


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?"