On Nov 18, 2007, at 1:50 PM, Chuck Remes wrote:

>
>
> On Nov 17, 2007, at 12:02 AM, Sharon Rosner wrote:
>
>>
>>> This code results in two database hits like so:
>>>
>>> I, [2007-11-16T13:15:11.468035 #1255]  INFO -- : INSERT INTO orders
>>> ( `market`, `date`, `order_id`) VALUES ( 'ICE', '20071114', '9104')
>>> I, [2007-11-16T13:15:11.468913 #1255]  INFO -- : SELECT * FROM  
>>> orders
>>> WHERE (`id` = 28838) LIMIT 1
>>>
>>> The order instance obviously already knows the primary key since it
>>> uses it for the SELECT statement.
>>
>> Currently when you create a model record, it is SELECTed immediately
>> after being INSERTed, in order to retrieve all the columns and any
>> default values belonging to the model instance. I think this makes
>> sense in many cases, but there's the performance penalty. If it's
>> really important to you, I can look at offering an alternative
>> behavior.
>
> Yes, let's take a look at some alternatives. I agree that this
> behavior should be default. It certainly follows the Principle of
> Least Surprise. But for us performance-conscious folks, the extra
> select can oftentimes be superfluous particularly if we aren't using
> column defaults.
>
> I took a look at the Sequel::Model definition for +save+ where  
> +refresh
> + does this immediate select. It would be handy if we could pass in
> optional parameters when defining our Models to selectively turn off
> this type of behavior. Here's an example:

Thinking out loud here...

Does it make more sense to add a default +after_create+ hook that  
calls +refresh+? To override the behavior we could remove that hook.  
This presupposes that we can name the hooks we push into the hook 
[:after_create] array. We would need an additional instance method  
that would allow the deletion of the named hook. Alternately, make  
the auto-refresh something that needs to be explicitly turned on by  
the programmer when defining the model. This saves the effort of  
naming the specific hooks and changing the API to allow deletion of it.

Think this is cleaner than lots of "unless opts[:some_special_val]"  
type calls embedded elsewhere in the code?



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"sequel-talk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sequel-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to