Base qui ne respect pas les conventions rails

Bonjour,
J’utilise une base de données qui ne suit pas du tout las convention
rails.
J’ai trouvé quelques infos et j’aimerai que vous affirmer ou infirmer ce
que je vais dire.

Le nom des tables ne suit pas la convention :

J’ajoute dans config\environement.rb cette ligne :
 ActiveRecord::Base.pluralize_table_names = false

Si je genere un modèle par exemple Tomate par la commande :
ruby script\generate model Tomate

le fichier suivant sera crée
create db/migrate/001_create_tomates.rb

et je pourrais crée ma table qui repond au nom de tomate
create_table(:tomate)

Le nom des colonnes ne suit pas la convention :

Je n’ai pas de champs id mais des clefs primaire de type varchar qui
coresponde a des numeros de series ex F0034
Je definie dans ma classe Tomates la clef primaire

class Tomate < ActiveRecord::Base
set_primary_key “numero_serie”
end

Comme Active record utilise l’attribut id, Dans le code, lors de
l’appelle a la valeur, Active recorde veux qu’on utilise tomate.id et
non tomate.numero_serie

2008/6/9 Mazraelle M. [email protected]:

 ActiveRecord::Base.pluralize_table_names = false
Le nom des colonnes ne suit pas la convention :
l’appelle a la valeur, Active recorde veux qu’on utilise tomate.id et
non tomate.numero_serie

Tu peux utiliser aussi set_table pour définir la table de ton modèle.


Cyril M.

on utilise le set table en plus ou a la place?

2008/6/9 Mazraelle M. [email protected]:

on utilise le set table en plus ou a la place?

Ca dépend. Tu peux l’utiliser a la place surtout si ta classe est même
pas forcement au pluriel.

Ex:

Table :GRI_POST

class Post < ActiveRecord::Base
set_table_name ‘GRI_POST’
end

et tu pourras manipuler ton objet Post qui se trouve dans la table
GRI_POST

J’ai personnelement utilisé plusieurs technique de correspondance
d’objet ActiveRecord avec des Tables non formaté Rails, dans mon
projet d’importateur de blogware pour Typo[1]

[1] : GitHub - shingara/typo_converteur: A converteur from another blog engine to Typo blog


Cyril M.