Is RefetchAfterSave done in same sql statement?

Posts   
 
    
mihies avatar
mihies
User
Posts: 800
Joined: 29-Jan-2006
# Posted on: 29-Jan-2006 17:04:33   

Hi guys,

(newbie performance questions) 1. I wonder if refetch after save is done in the same statement? 2. I also wonder whether LLBLGen supports batch updates (like sqldataadapter 2005 does)?

thanks

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39930
Joined: 17-Aug-2003
# Posted on: 29-Jan-2006 19:10:57   

mihies wrote:

Hi guys,

(newbie performance questions) 1. I wonder if refetch after save is done in the same statement?

no, a separate select, as some databases don't support batching in their provider.

  1. I also wonder whether LLBLGen supports batch updates (like sqldataadapter 2005 does)? thanks

No, as that lowlevel batching feature is hardcoded for sqldataadapter in the sqlclient and MS isn't willing to open up the code as that would cause a redesign of what they wrote.

Frans Bouma | Lead developer LLBLGen Pro
mihies avatar
mihies
User
Posts: 800
Joined: 29-Jan-2006
# Posted on: 29-Jan-2006 19:43:53   

Hi Frans,

Otis wrote:

mihies wrote:

Hi guys,

(newbie performance questions) 1. I wonder if refetch after save is done in the same statement?

no, a separate select, as some databases don't support batching in their provider.

  1. I also wonder whether LLBLGen supports batch updates (like sqldataadapter 2005 does)? thanks

No, as that lowlevel batching feature is hardcoded for sqldataadapter in the sqlclient and MS isn't willing to open up the code as that would cause a redesign of what they wrote.

  1. Perhaps you might tweak it for providers that support it - it is never a bad idea to avoid a round trip? Also, I guess an option to refetch only required data would be perforamce wise (to fetch only server-side changes such as timestamps, calculated values, etc.)

  2. I think (didn't yet look at the thing) that batching is acomplished by creating a new set of parameters for every row (by adding a number to the origanals). for example: If you have insert into table (field) value (@field) the batching for two rows would look like: insert into table (field) value (@field); insert into table (field) value (@field1) Shouldn't be that difficult to implement while the gain might be quite big.

What do you think?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39930
Joined: 17-Aug-2003
# Posted on: 29-Jan-2006 21:10:48   

Hi Miha simple_smile

mihies wrote:

Hi Frans,

Otis wrote:

mihies wrote:

Hi guys, (newbie performance questions) 1. I wonder if refetch after save is done in the same statement?

no, a separate select, as some databases don't support batching in their provider.

  1. I also wonder whether LLBLGen supports batch updates (like sqldataadapter 2005 does)? thanks

No, as that lowlevel batching feature is hardcoded for sqldataadapter in the sqlclient and MS isn't willing to open up the code as that would cause a redesign of what they wrote.

  1. Perhaps you might tweak it for providers that support it - it is never a bad idea to avoid a round trip? Also, I guess an option to refetch only required data would be perforamce wise (to fetch only server-side changes such as timestamps, calculated values, etc.)

It's not that simple unfortunately. Of course, I can change the code to support it, the problem is that the refetch is simply calling a fetch on the entity, while re-reading identity /sequence info is done by the save code for example, this means that the architecture has to change a lot.

Only fetching server-assigned values is doable in theory, only if you know which NULL values have a default set. This isn't always known. (and currently not known in the meta-data per field). So it does a refetch on the entity as a whole, if you want to have a refetch. Identity/pk values are always read back.

  1. I think (didn't yet look at the thing) that batching is acomplished by creating a new set of parameters for every row (by adding a number to the origanals). for example: If you have insert into table (field) value (@field) the batching for two rows would look like: insert into table (field) value (@field); insert into table (field) value (@field1) Shouldn't be that difficult to implement while the gain might be quite big. What do you think?

If I'm not mistaken they pack the statements on a lower level (the raw sql-client (dbclient) layer). the problem with a lot of parameters is that the server isn't helped by that. But if you pre-process the queries first and send the statements on a lower level packed to the server, that can help, however MS refused to open the API for 3rd parties. The method is there, it's just made internal. disappointed

Frans Bouma | Lead developer LLBLGen Pro