This problem seems to be more widespread:
xx = "safe string".html_safe
xx.underscore
xx.titlecase
xx.pluralize
Each inflection throws the same exception. Inflections should be safe
operations...shouldn't they?
(although xx.(upcase|downcase|dasherize) are fine)
On Jun 9, 5:11 am, Ryan Bigg wrot
I feel that the conventional use case of validations is returning the
object with the errors attribute(s) set to let you know which parts
failed. A validation is used to confirm that user data entry conforms
to necessary constraints, in normal processing (ie. a controller
calling record.save) the
+1 any damn thing.
+1 to be accepting of change down the road.
We won't really know and understand the impact of having a default JS
test apparatus until its put in there and the feedback comes back in
from production people over the course of a year or two.
--
You received this message becaus
AFAIK there is no support for prepared statements baked in.
If you want them you need to use the SQL connection directly (and
potentially become DB specific). Last time I looked, awhile ago now, there
wasn't a production ready gem to supply reasonable prepared statement
support.
Simon
--
Yo
Ahh. Yes.
I misunderstood your question.
It is the case that the #find* methods have some magic baked into them
that aren't in the rest of the query stack. They are the "highest level" so
the #where and arel calls would have to reach "up" to get them... With the
performance hit.
... IANA co
My experience includes having to whitelabel my whole application, putting
it under a new domain name, with a small subset of configuration options
changing for each deployment. This has led to me having environments for
client acceptance, staging, along for each whitelabel. Managing all these
It appears that you have to be explicit in specifying the files that get
compiled.
config.assets.precompile += %(asset1.js asset2.js style1.css)
The default just contains application.(css|js)
Hopefully this assists you.
On Thursday, 24 May 2012 12:30:02 UTC-4, Rodrigo Rosenfeld Rosas wrote:
>
I came to this same problem and think that it may perhaps need some
convention...First my current solution to this. Suggestion to Rails Core
at the bottom.
My solution came from "defining" an api subdirectory/route namespace and
that all routes under that namespace are ones to be exported to v
FWIW: This subtle difference disturbed me so much that I just alias
update_attribute to update_attribute*s*.
I'm very pleased to learn about update_column for the strange edge case
where you need it direct.
+1 for deprecation and emphasizing update_column.
On Thursday, 14 June 2012 08:31:22
I would be -1 on this sort of change.
Changing the schema of a RDBS and deploying the dependent code should be
performed with great care, the basic concept of each migration being
"whole" change keeps things tidy. Giving any impression to a developer
that enclosing a bunch of migrations as a t
10 matches
Mail list logo
