ActiveRecord::Base.connection
a un quote
qui prend une valeur de type chaîne de caractères (et éventuellement l'objet colonne). Vous pouvez donc dire ceci
ActiveRecord::Base.connection.execute(<<-EOQ)
UPDATE foo
SET bar = #{ActiveRecord::Base.connection.quote(baz)}
EOQ
Notez que si vous êtes dans une migration Rails ou un objet ActiveRecord, vous pouvez raccourcir cela en :
connection.execute(<<-EOQ)
UPDATE foo
SET bar = #{connection.quote(baz)}
EOQ
UPDATE : Comme le souligne @kolen, vous devriez utiliser exec_update
à la place. Cela permet de gérer la citation pour vous et d'éviter les fuites de mémoire. La signature fonctionne cependant un peu différemment :
connection.exec_update(<<-EOQ, "SQL", [[nil, baz]])
UPDATE foo
SET bar = $1
EOQ
Ici, le dernier paramètre est un tableau de tuples représentant les paramètres de liaison. Dans chaque tuple, la première entrée est le type de colonne et la seconde est la valeur. Vous pouvez donner nil
pour le type de colonne et Rails fera généralement ce qu'il faut.
Il existe également exec_query
, exec_insert
y exec_delete
en fonction de vos besoins.
0 votes
Pourquoi voulez-vous faire cela en utilisant le SQL brut, le but d'ActiveRecord est de vous aider à éviter cela...
0 votes
Si j'utilise AR, je dois d'abord obtenir Model Object par la méthode find d'AR avec le champ id, puis faire l'opération de mise à jour. Donc, du point de vue des opérations, un UPDATE AR nécessite deux sql avec la base de données ; d'autre part, je ne suis pas sûr que la méthode de mise à jour de AR utilise une liaison dynamique. Je veux donc utiliser un sql brut avec une liaison dynamique pour une interaction avec la base de données pour l'opération de mise à jour, mais je ne sais pas comment passer des paramètres pour remplacer le ? dans le sql par AR.
32 votes
Il y a de nombreuses raisons valables de le faire. Tout d'abord, la requête peut être trop complexe pour être traduite en utilisant la méthode Ruby habituelle... Ensuite, les paramètres peuvent contenir des caractères spéciaux comme % ou des guillemets, et c'est un casse-tête d'échapper les...
3 votes
@Andrew, il est préférable d'utiliser les fonctions mysql brutes plutôt que d'accepter la "commodité" qu'offre AR.
5 votes
@Green pas si vous voulez un jour déplacer votre application de MySQL à PostgreSQL ou autre. L'un des principaux objectifs d'un ORM est de rendre votre application portable.
0 votes
Andrew Un mot : les migrations. Pendant une migration, vous ne pouvez pas compter sur la commodité d'ActiveRecord.