Legacy database

Community FR
1

Bonjour,

Petite question sur l’utilisation de base existantes. J’ai essayé de
lire
la prose sur ce sujet, sans vraiment trouver de reponse concluante. J’ai
donc une base existante, ok, on peut donner le nom de la table active
record, lui specifier l’index, etc…
Mais est il possible de renommer les champs pour les rendres plus
“programmeur friendly”? Notamment si ils ne suivents pas les regles
ruby?

2

Thomas:

Petite question sur l’utilisation de base existantes. J’ai essayé
de lire la prose sur ce sujet, sans vraiment trouver de reponse
concluante. J’ai donc une base existante, ok, on peut donner le
nom de la table active record, lui specifier l’index, etc…

(petite remarque au passage, les points de suspension sont
inutiles après etc., c’est redondant, un peu comme descendre
en bas)

Mais est il possible de renommer les champs pour les rendres
plus “programmeur friendly”? Notamment si ils ne suivents pas
les regles ruby?

Avec Edge et 1.2RC1, tu peux utiliser alias_attribute :

class Ga < AR::B
alias_attribute :titre, :gabumeuzo
end

Donc tout se passe comme si ta colonne ‘gabumeuzo’ de ta table
gas est remplacée par ‘titre’.

ga = Ga.new
ga.titre = …

Pour Rails 1.1.*, tu peux soit backportercette fonctionnalité, ou
utiliser la méthode classique :

class Ga < AR::B
def titre
read_attribute(‘gabuzomeu’)
end

def titre=(value)
write_attribute(‘gabuzomeu’, value)
end
end

-- Jean-François.
3

Samuel :

[…]

def titre=(value)
write_attribute(‘gabuzomeu’, value)
end
end

[Attention, intermède immature]

Attention, c’est ‘gabumeuzo’ ou ‘gabuzomeu’, ou la version 1.2
est-elle à ce point là intelligente pour s’y retrouver (avec une
nouvelle lib ActiveShadock ?!?) ? :wink:

Je suis pas un spécialiste shadokien, mais gabumeuzo a une
signification particulière et gabuzomeu, une différente.

Ainsi :
bu meu zo ga, visiblement (google) ça veut dire triste et très assoiffé.

Mais je retiens l’idée de faire un DSL shadokien en Ruby, pour faire
du Développement Dirigé par le Pompage.

Une autre solution, (là je vais me faire tirer dessus à boulet rouge par les
puristes), mais il y a les vues, à condition bien sûr qu’elles permettent
l’update et la création dans la table cible…

ce qui n’est pas toujours possible, selon le sgbdr.
(ya un plugin à ce sujet, acts_as_view)

РJean-Fran̤ois.

4

2006/12/18, Jean-François [email protected]:

Donc tout se passe comme si ta colonne ‘gabumeuzo’ de ta table
read_attribute(‘gabuzomeu’)
À la renverse.

Railsfrance mailing list
[email protected]
http://lists.rubyonrails.fr/mailman/listinfo/railsfrance

Attention, c’est ‘gabumeuzo’ ou ‘gabuzomeu’, ou la version 1.2 est-elle
à ce
point là intelligente pour s’y retrouver (avec une nouvelle lib
ActiveShadock ?!?) ? :wink:

Une autre solution, (là je vais me faire tirer dessus à boulet rouge par
les
puristes), mais il y a les vues, à condition bien sûr qu’elles
permettent
l’update et la création dans la table cible…

Samuel

5

Thomas L. wrote :
| Bonjour,

Bonsoir,

| Petite question sur l’utilisation de base existantes. J’ai essayé de lire
| la prose sur ce sujet, sans vraiment trouver de reponse concluante. J’ai
| donc une base existante, ok, on peut donner le nom de la table active
| record, lui specifier l’index, etc…
| Mais est il possible de renommer les champs pour les rendres plus
| “programmeur friendly”? Notamment si ils ne suivents pas les regles
| ruby?

Oui, après tout dépend de ce que tu veux faire … Dans mon cas, la
database existante possédaient des noms qu’on pourraient qualifier
d’opposé de Rails: en CamelCase (vac parfois des exceptions, par exemple
sur des acronymes), avec des noms de tables au singulier … etc …

Avec une petite couche d’adaptation, l’appli est maintenant codée selon
les conventions rails (Foo.bar) même si elle accède à la colonne Bar de
la table Foos …

Mes 0.0002 cents

Frederick R. aka Sleeper – [email protected]

printk(“autofs: Out of inode numbers – what the heck did you do??\n”);
linux-2.0.38/fs/autofs/root.c

6

Oui, après tout dépend de ce que tu veux faire … Dans mon cas, la
database existante possédaient des noms qu’on pourraient qualifier
d’opposé de Rails: en CamelCase (vac parfois des exceptions, par exemple
sur des acronymes), avec des noms de tables au singulier … etc …

De mon côté j’ai développé des outils visant SQL Server 2005 avec
ActiveRecord, la base étant en nommage legacy. J’ai opté pour conserver
le
nom tel qu’il l’était en base pour que ça soit plus facile de faire le
lien,
mais en le DRYant au passage. Ex: des tables dont le nom est
T_PEOPLE_PPL
(type/nom complet/alias), avec des colonnes comme PPL_ID,
PPL_FIRST_NAME,PPL_LAST_NAME, sont rubyfiées à l’aide de method_missing
en
un modèle qui s’appelle People, avec des méthodes first_name, last_name
(en
minuscule), sans le préfixe PPL devant.

Au passage pour ceux qui attaquent des bases legacy, jettez un oeil Ã
DRYsql
(http://drysql.rubyforge.org/). Il infère la plupart des éléments Ã
partir
de la base elle même, au lieu d’avoir à expliciter à ActiveRecord le nom
de
la clé primaire, de la clé étrangère etc… A regarder.

Thibaut