search

spkhillar / hibernate-generic-dao

Automatically exported from code.google.com/p/hibernate-generic-dao
0 stars 0 forks source link

split search.fetch into search.select and search.eager #20

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
We have been using the fetch option on search for two very distinct things:
(1) selecting individual properties to return for each result
(2) eagerly fetching relationships of the main result entity

Which of these operations is performed is determined by the search's fetch 
mode.

It seems to me that it might be better to separate these two ideas to avoid 
confusion. An additional benefit is that it may be possible to do both at 
the same time: For example if the root search entity is a kitten and the 
mother property should be returned and the list of the mother's children 
should be eagerly fetched.

I'm trying to decide what to call these two individual options. Right now 
I'm considering "select" for (1) and "eager" or maybe "fetch" or "fill" for 
(2).

Original issue reported on code.google.com by dwolvert on 17 Dec 2008 at 4:11

GoogleCodeExporter commented 9 years ago 
Brainstorming...

addSelect()
addFetch()
addFill()
addEager()*
addEagerFetch()
addPull()
addColumn()*
addProjection()
addSelection()
addScalar()
addReturn()
addField()*
addData()
addGet()
addInclude()
addEntry()

Original comment by dwolvert on 2 Jan 2009 at 3:25

GoogleCodeExporter commented 9 years ago 
I'm going to implement this using Field and Fetch. fetchMode will become 
resultMode.

Original comment by dwolvert on 5 Jan 2009 at 4:10

GoogleCodeExporter commented 9 years ago

Original comment by dwolvert on 5 Jan 2009 at 4:10

GoogleCodeExporter commented 9 years ago 
Changes implemented for 0.4.1.

Original comment by dwolvert on 5 Jan 2009 at 6:39