Re: [Rails-core] Redesign the Rubyonrails.org
Hi! Please elaborate. Where do you think the site is lacking? How can we improve it? Maybe make it more like http://ruby-lang.org/ and less BaseCamp? Ie. a simpler, more traditional structure, with all the latest news right there on the front page. Thanks! Frank P.S. An announce mailinglist would also be greatly appreciated! 2014-12-23 3:11 GMT+01:00 Ryan Bigg radarliste...@gmail.com: Please elaborate. Where do you think the site is lacking? How can we improve it? On 20 Dec 2014, at 18:50, Anandu B Ajith reach2ana...@gmail.com wrote: The site is having a very old design and not usable .. shouldn't we switch to a better design in 2015?? -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
Re: [Rails-core] Redesign the Rubyonrails.org
* less like BaseCamp 2014-12-23 13:37 GMT+01:00 Frank Tellefsen tellefsenfr...@gmail.com: Hi! Please elaborate. Where do you think the site is lacking? How can we improve it? Maybe make it more like http://ruby-lang.org/ and less BaseCamp? Ie. a simpler, more traditional structure, with all the latest news right there on the front page. Thanks! Frank P.S. An announce mailinglist would also be greatly appreciated! 2014-12-23 3:11 GMT+01:00 Ryan Bigg radarliste...@gmail.com: Please elaborate. Where do you think the site is lacking? How can we improve it? On 20 Dec 2014, at 18:50, Anandu B Ajith reach2ana...@gmail.com wrote: The site is having a very old design and not usable .. shouldn't we switch to a better design in 2015?? -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
[Rails-core] Re: Redesign the Rubyonrails.org
Yes, a redesign is currently being worked on. On Saturday, December 20, 2014 12:50:35 AM UTC-7, Anandu B Ajith wrote: The site is having a very old design and not usable .. shouldn't we switch to a better design in 2015?? -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
[Rails-core] Re: ActiveRecord model attribute definition with type caster and default
This is not currently public API, the final API will likely support default
values when it is made public in the future.
On Tuesday, December 23, 2014 2:19:14 AM UTC-7, Benji wrote:
[Braindump]
I stumbled on the code to define an attribute in the model. Since my
personal opinion is that default and type logic of an attribute is the
responsibility of the model and not of a database column type I was really
happy to see the code appear in rails:
https://github.com/rails/rails/blob/master/activerecord/lib/active_record/attributes.rb#L78
The current implementation of the attribute method requires a mandatory
second argument type caster object. Since active record has a very good
mechanism of creating a good default type caster based on a database column
I suggest to use it for this method. In pseudo monkey patch code:
class MyModel ActiveRecord::Base
def self.attribute(name, options = {})
type_caster = options.delete(:type) ||
columns_hash[name.to_s].cast_type
super(name, type_caster, options)
end
attribute :my_number, default: 5
attribute :price_in_cents, type: MoneyType.new
end
aka, make the type caster an option, not a required argument and fall back
to the default based on the database column type.
Thanks for all the good work!!
Benjamin ter Kuile
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.
Re: [Rails-core] Proposal for before_transaction callback
On Dec 19, 2014, at 8:18 PM, Jesse Storimer je...@shopify.com wrote: I'd like to propose adding another callback to the ActiveRecord lifecycle that triggers BEFORE the database transaction begins. Think of it as a corollary to after_commit and after_rollback. ## Examples This is an example resembling something we have to deal with in the Shopify codebase. This is how it could be written using this new callback. class CarrierService ActiveRecord::Base validate :username, :password, presence: true validate :validate_credentials before_transaction :initiate_credential_validation def initiate_credential_validation logger.debug 'communicating with external carrier...' @response = external_service.validate(username, password) end def validate_credentials if ! @response.valid? # add validation error here end end end Imagine an interaction like this: carrier = CarrierService.new(username: 'jesse', password: 'password') carrier.save producing a log like this: communicating with external carrier... (0.1ms) begin transaction SQL (0.4ms) INSERT INTO carrier_services (username, password) VALUES (?, ?) [[username, jesse], [password, password]] (1.9ms) commit transaction Note that the external communication happens before the transaction begins. We are doing this currently in our codebase, but it doesn't fit nicely into the traditional ActiveRecord callback cycle. Another obvious place where this would be beneficial is for models that represent assets / uploads that want to fetch the asset on creation but not inside the transaction. It seems like a `before_save` that, in case of failure, adds something to `errors` and returns false would accomplish the same thing here. It would only run if the validations all otherwise pass, and it would make `save` return false if it failed. Something like: class CarrierService ActiveRecord::Base validate :username, :password, presence: true before_save :validate_credentials def validate_credentials @response = external_service.validate(username, password) unless @response.valid? errors.add(:base, ‘YOU DONE GOOFED’) false end end end ## Motivation The motivation for this addition is the same as for the after_commit callback. Some models need to communicate with external services in order to do validations / callbacks. To do so inside the DB transaction keeps that transaction open unnecessarily and wreaks havoc on the DB. ## Gotchas The above example involving a single model being saved with the callback defined is the simple case. It can get more complicated in a scenario like the following: class Shop ActiveRecord::Base end class ProductImage ActiveRecord::Base before_begin :fetch_image end shop = Shop.find(1) shop.images ProductImage.new(src: '...') shop.images ProductImage.new(src: '...') # before opening the transaction to save the shop, we must look for autosave associations # and see if they have before_begin callbacks that need to be triggered shop.save We have prototyped a mostly functional supporting this relationship, so it can certainly be accomplished. This functionality would not play very nicely with the explicit transaction methods. For instance, when using .transaction this kind of callback could never be triggered reliably. shop = Shop.find(1) Shop.transaction do # we're already in a transaction at this point, so the callback has no hope of being triggered outside of this parent transaction Product.create(..., shop: shop) ProductImage.create(..., shop: shop) end We would have a little more context when using the #transaction method given that it's called on an instance that may have this callback defined (or have unsaved associations with this callback defined), but it could be used exactly as in the previous example and circumvent the process. So the callback would fit in nicely during the regular `save` lifecycle, but the explicit transaction methods would be a gotcha when using this feature. The problem is that explicit transactions are implicitly part of *every* save. Traversing associations beforehand is a decent approximation, but code that updates / creates a record in an `after_save` is still going to require time travel to achieve the intended semantics. In the case of your Product / ProductImage setup, this would produce a bug: class Product has_many :product_images after_save :create_default_image def create_default_image if product_images.empty? product_images ProductImage.create(src: ‘some/default/path’) end end end ProductImage’s before_transaction callback CANNOT run at the right time here, since it’s fired from a place that MUST already be contained in an open transaction. Sadly, `gem install tardis` does not help. :) The before_save suggestion
[Rails-core] Re: ActiveRecord model attribute definition with type caster and default
Nice!
On Tuesday, 23 December 2014 15:57:54 UTC+1, Sean Griffin wrote:
This is not currently public API, the final API will likely support
default values when it is made public in the future.
On Tuesday, December 23, 2014 2:19:14 AM UTC-7, Benji wrote:
[Braindump]
I stumbled on the code to define an attribute in the model. Since my
personal opinion is that default and type logic of an attribute is the
responsibility of the model and not of a database column type I was really
happy to see the code appear in rails:
https://github.com/rails/rails/blob/master/activerecord/lib/active_record/attributes.rb#L78
The current implementation of the attribute method requires a mandatory
second argument type caster object. Since active record has a very good
mechanism of creating a good default type caster based on a database column
I suggest to use it for this method. In pseudo monkey patch code:
class MyModel ActiveRecord::Base
def self.attribute(name, options = {})
type_caster = options.delete(:type) ||
columns_hash[name.to_s].cast_type
super(name, type_caster, options)
end
attribute :my_number, default: 5
attribute :price_in_cents, type: MoneyType.new
end
aka, make the type caster an option, not a required argument and fall
back to the default based on the database column type.
Thanks for all the good work!!
Benjamin ter Kuile
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.
Re: [Rails-core] Redesign the Rubyonrails.org
I just checked again, and everything looks pretty good. Only it could have better support for retina screens. On December 23, 2014 at 8:11:15 AM, Ryan Bigg (radarliste...@gmail.com) wrote: Please elaborate. Where do you think the site is lacking? How can we improve it? On 20 Dec 2014, at 18:50, Anandu B Ajith reach2ana...@gmail.com wrote: The site is having a very old design and not usable .. shouldn't we switch to a better design in 2015?? -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout. — Thanks, Almas Sapargali http://almassapargali.com -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
[Rails-core] Add Support for creating and dropping SQL views
I'l like to see a simple interface for add, drop and update SQL views in rails. Could you open the dicussion at github again? https://github.com/rails/rails/pull/18153#issuecomment-67962377 -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
[Rails-core] Add Support for creating and dropping SQL views
I'd like to add an simple interface to add, drop and create sql views in rails instead of use an another dependency. Can we reopen the discussion at github? https://github.com/rails/rails/pull/18153#issuecomment-67962377 -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
[Rails-core] Re: feature request (with demo code): native websockets as controller callbacks.
I added code that automates the #broadcast to use a Redis server (if defined). I think having these features in Rails, where a controller can respond to websocket events, is critical for moving forward. Using middleware and dedicated event machines to handle parts of the application means that the developers are moving away from the framework and the code is less well organized and harder to maintain. Having the framework respond to both RESTful requests and WebSocket requests, like in this experimental framework https://github.com/boazsegev/anorexic, feels essential in this worlds where http and webs apps act also as the backend for mobile apps and other advanced clients. Feel free to ask any questions, I would love if these websocket features were assimilated in Rails. On Wednesday, December 3, 2014 6:04:48 PM UTC-5, Boaz Segev wrote: Hi, I was thinking about this a lot and even found myself writing a whole server / framework with native websocket support https://github.com/boazsegev/anorexic to see what was possible. Websockets is far too complicated to to easily utilize in it's present state, since using websockets in Rails applications requires Rack and Middleware knowhow which is not expected from the average Rails developer and isn't common. I propose adding support for native websockets within the Controller class - by defining callback support for the following methods / events: `pre_connect` (before protocol upgrade, for updating cookies and HTTP data), `on_connect` (after protocol upgrade), `on_message(data)`, `on_disconnect`. this also might require adding support for controller class instance communication, assuming each connection has it's own controller instance - this could allow us to broadcast messages and collect information from other connections directly (without pulling on databases or setting up flags)... I've managed an interesting solution within the `broadcast` and `collect` methods in my experimental framework. If anyone thinks this is a good approach, please feel free to contact me about adapting my code (or writing new code) for the Rails 5.0 release. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
