Re: Re: findReferencing?

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>[email protected], 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: [email protected]
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?"



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

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/