Re: Mananged many-to-one references

Hello Mike,

 From the Demo:-

List<Employee> emps = ses.query(new SQuery(Employee.EMPLOYEE)
    .eq(Employee.DEPARTMENT, d100q).descending(Employee.SALARY);

I would not normally suggest that you go near the SDataSet explicitly -- it is just an option in some advanced cases.  If you want to get all Employees in Sales Orderd By Name just run a query -- it is only one line of code -- and store the result in a list.  That is what needs to be done in any case.  Very occasionally you might want to add a simple variable on the Department to hold that list.

Do you have a specific problem, or are you just trying to understand the semantics?

Hibernate is certainly not less verbose than SimpleORM, particularly with all the getters and setters etc.  Indeed until they got rid of the XML quite the opposite.  Hibernate also enables Department Sales to contain Employee Fred, and Fred.Department to be Engineering, both at the same time (without any many to many table).  Generally the last update seems to win when you update.  A real problem with their Association approach which they acknowledge.  Also, the Many end is not sorted, which greatly limits its usefulness in practice.

Regards,

Anthony

At 11:07 AM 15/04/2010, Mike Goodwin wrote:
>  
>
>Hi Franck, Anthony
>
>Thanks for the responses, I think I understand the required approach now.
>
>My initial impression is that SimpleORM is essentially correct. It feels intrusive and a bit more verbose, but they are both good things,  because it forces persistent considerations to be handled, and everything is explicit and understandable. Conversely hibernate ...etc. have perhaps gone to far trying to eliminate all verbosity and intrusion and in doing so have created a lot of edge cases and gotchas. 
>
>Still, I think the main issue I have is that the because the SDataSet is constructed procedurely it can become hard to know exactly what it contains at different points in a program. I accept that the many-to-one does not require managing especially from a data management point of view, but I still think it can be useful for describing the data being managed. In a sense the way it is now, the records in an SDataSet are implicit on the preceding logic. 
>
>In other words it might be nice if data sets could be done in a more declarative manner, perhaps this could be based ontop of the SDataSet as it is currently. In this scheme there would need to be a way to declare a many-to-one in an entity. For data sets with more than a single root piece of data, probably another umbrella type would be necessary, with it's own meta data.
>
>Many-to-one data items could be declared with a filter/query, but by default you would get all.
>
>Loading a dataset would then become a single step (it would resolve all references and fetch, by default). Added data would have to belong within the declared hierarchy. Queries should be performable against a dataset or against the database.
>
>Just my ideas, possibly a bit premature,
>
>regards,
>
>mike
>
>


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:
    [email protected] 
    [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/