Rails core - Mar 2007 - Active Record proposal/discussion for improvement

Hello,

I have started in "Ruby on Rails: Talk" a discussion about my problems
with current ActiveRecord implementation. Please take a look here:
http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/d40b754fc5872a99/47cff815df123b8a?lnk=gst&rnum=2

Regards
Oliver Paulus


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On 3/2/07, Oliver Paulus <oliver@code-project.org>
wrote:
>
> Hello,
Hi,

What about the current behaviour is causing you problems?   Reducing
the number of columns updated is extremely dangerous without using
locking of some sort as there''s no way for the models to enforce the
validations.



-- 
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

> What about the current behaviour is causing you problems?   Reducing
> the number of columns updated is extremely dangerous without using
> locking of some sort as there''s no way for the models to enforce
the
> validations.
The problem is the following: If I want to have an Attachment (Upload)
entity with the acts_as_list (position) column - ActiveRecord makes a
full update (with the blob content) on each position change (with
move_higher). Now I had to use a has_one relation (and added another
entity for the content, etc.) and using native SQL for doing the
listing - because I do not have the attachment name in entity A and
the blob entity (DRY principle).
Another problem: If I have an Entity with a "published" flag and on
another page I have the "edit entity" functionality. If I click on
publish this entity (page A) ActiveRecord is making a full update -
instead of updating only the flag (or datetime column). Another user
can be on edit page to change content on page B. In this case - in the
ActiveRecord case the last update wins - and the changes before get
lost.
> Reducing the number of columns updated is extremely dangerous without using
> locking of some sort as there''s no way for the models to enforce
the
> validations.
The model can be validated too - the complete record is available -
only the generated update can be smaller.
And a locking feature is OK - if I want to have it. Hibernate e.g.
provides locking too (see
http://www.hibernate.org/hib_docs/v3/reference/en/html/transactions.html#transactions-optimistic,
http://www.hibernate.org/hib_docs/v3/reference/en/html/transactions.html#transactions-locking).

The main problem is that ActiveRecord is very nice and easy to use -
in the first view. I love Rails and started the "easy" way to
implement my things. Then I saw some problems - described above. Using
SQL is annoying me because the code is not so portable and more
complicated. I had to add another entity to decouple the
"acts_as_list" entity from the blob entity. This makes my program more
complicated and I cannot use the simplest way. The other principles in
Rails are in this way "do it simple" - but some ActiveRecord things
can become a pitfall if you are using it in this way. I think it would
be nice to have an O/R Mapper (persistence layer) that is more
flexible - to keep in ActiveRecord more often - and avoid native SQL
(more often). Another problem in my point of view is that a full
update on all columns can be a performance issue too - on entities
with a lot of properties.
Another issue is the following: I thought the "update_attribute" do
only the update on the one attribute - but it makes a full update.
That was a little bit confusing to me.
Perhaps acts_as_list can be changed that only the position column will
be updated on position change - e.g. with move_higher.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

> Another problem: If I have an Entity with a "published" flag and
on
> another page I have the "edit entity" functionality. If I click
on
> publish this entity (page A) ActiveRecord is making a full update -
> instead of updating only the flag (or datetime column). Another user
> can be on edit page to change content on page B. In this case - in the
> ActiveRecord case the last update wins - and the changes before get
> lost.
What you''ve outlined here is precisely the risk for partial updates.
Your model validations will ensure that each of the individual models
are internally consistent, then proceed to write only their changes to
the database.  The resulting record may, or may not, be valid, and
that''s too risky.
> The model can be validated too - the complete record is available -
> only the generated update can be smaller.
No it doesn''t as I''ve mentioned above.
> And a locking feature is OK - if I want to have it.Hibernate e.g.
> provides locking too (see
>
http://www.hibernate.org/hib_docs/v3/reference/en/html/transactions.html#transactions-optimistic,
>
http://www.hibernate.org/hib_docs/v3/reference/en/html/transactions.html#transactions-locking).
Rails supports both pessimistic and optimistic locking, just like
hibernate does.
> Perhaps acts_as_list can be changed that only the position column will
> be updated on position change - e.g. with move_higher.
If the only case where this makes a difference is entities with blobs,
then I don''t think it justifies the significant risk implied by
partial updates.

Are there any other cases?




-- 
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

I think it would be nice to have an option to choose if I want partial
updates or not. The default should be the full update. Then every
developer can choose. e.g. In the case of acts_as_list with no extra
relation to the blob I would choose the partial update option. In the
other cases I do not need to change the default. For performance
tuning the developers can test it with the option and without - to
decide if it is needed to have the model "full validated" - means the
validation of different fields in combination, because in the simple
case all fields are present and can be validated against "simple"
rules. If you have 2 or more fields which must be validated in
combination - you should choose the full update option (the default).
What do you think about this?


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

I think partial updates are so rarely desirable, and so rarely give a
significant speed increase, that it is better to force the developer
to use raw SQL in that situation.

Do others disagree?

Evan

On Mar 5, 11:44 am, "Oliver Paulus" <oli...@code-project.org>
wrote:
> I think it would be nice to have an option to choose if I want partial
> updates or not. The default should be the full update. Then every
> developer can choose. e.g. In the case of acts_as_list with no extra
> relation to the blob I would choose the partial update option. In the
> other cases I do not need to change the default. For performance
> tuning the developers can test it with the option and without - to
> decide if it is needed to have the model "full validated" - means
the
> validation of different fields in combination, because in the simple
> case all fields are present and can be validated against "simple"
> rules. If you have 2 or more fields which must be validated in
> combination - you should choose the full update option (the default).
> What do you think about this?

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On 05/03/07, Evan <eweaver@gmail.com> wrote:
>
> I think partial updates are so rarely desirable, and so rarely give a
> significant speed increase, that it is better to force the developer
> to use raw SQL in that situation.
>
> Do others disagree?
I agree.  Perhaps a plugin might be nice though, with syntax like:

class RecordWithBlob < ActiveRecord::Base
  update_only_when_changed :blob_attribute
end

I don''t have the need for such a plugin myself, but if someone did
want to put in the work, here''s one way to do it:

* intercept write_attribute to record which attributes are being changed
* intercept attributes_with_quotes to remove the marked attribute if
it hasn''t changed (and the record isn''t new)

When I say intecept, I mean use alias_method_chain to wrap around the
original implementations.

Tom

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

> I think partial updates are so rarely desirable, and so rarely give a
> significant speed increase, that it is better to force the developer
> to use raw SQL in that situation.
In case of acts_as_list and the move_higher method (e.g.) you have to
change your model design - I think an option like :dynamic_update =>
true would be fine for this case.
I love the Rails way of developing apps easily. If you use native SQL
your code gets more ugly. Why not add an :dynamic_update => true to
save, etc?


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

> In case of acts_as_list and the move_higher method (e.g.) you have to
> change your model design - I think an option like :dynamic_update =>
> true would be fine for this case.
> I love the Rails way of developing apps easily. If you use native SQL
> your code gets more ugly. Why not add an :dynamic_update => true to
> save, etc?
The best option here is for someone who''s really passionate about this
problem, i.e. yourself, to release a plugin which implements that
functionality.  Should it prove popular, we can investigate adding it
to rails itself.

-- 
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

I wrote a plugin a while ago that did partial updates:

http://svn.viney.net.nz/things/rails/plugins/acts_as_changed/

I haven''t used it recently but it probably still works with Rails edge.
It
might give someone a head start on implementing something similar.

-Jonathan.

On 3/6/07, Michael Koziarski <michael@koziarski.com>
wrote:
>
>
> > In case of acts_as_list and the move_higher method (e.g.) you have to
> > change your model design - I think an option like :dynamic_update
=>
> > true would be fine for this case.
> > I love the Rails way of developing apps easily. If you use native SQL
> > your code gets more ugly. Why not add an :dynamic_update => true to
> > save, etc?
>
> The best option here is for someone who''s really passionate about
this
> problem, i.e. yourself, to release a plugin which implements that
> functionality.  Should it prove popular, we can investigate adding it
> to rails itself.
>
> --
> Cheers
>
> Koz
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---