Salve a tutti,
Mi chiedevo come procedereste voi quando, in un’applicazione Rails,
dovete
appoggiarvi ad un DB preesistente (MS SQL Server) in cui ogni tabella ha
una chiave composta.
Inizialmente, andavo di :options nello specificare le foreign key, poi
ho
installato la gem “composite_primary_keys” (0.8.2) ed ho sperimentato
che,
nelle condizioni di cui sopra, non funziona.
Non funziona significa:
Quando le 2 tabelle in relazione:
-
hanno lo stesso numero di componenti come chiave primaria mi viene
restituito un errore di “Uninitialized constant”
-
hanno diverso numero di componenti, sia utilizzando :options che
passando fisso il valore di una delle componenti, la ricerca in quella
con un numero maggiore
delle stesse, fallisce perchè alle componenti in più viene assegnato
irrimediabilmente “nil”.
Detto ciò, voi come fate? Rimetto tutto “a base di :options”?
Grazie per il Vs aiuto
On 4/20/07, Carmine M. [email protected] wrote:
installato la gem “composite_primary_keys” (0.8.2) ed ho sperimentato
- hanno diverso numero di componenti, sia utilizzando :options che
passando fisso il valore di una delle componenti, la ricerca in quella
con un numero maggiore
delle stesse, fallisce perchè alle componenti in più viene assegnato
irrimediabilmente “nil”.
Detto ciò, voi come fate? Rimetto tutto “a base di :options”?
Potresti forse creare delle view che siano più conformi allo stile di Rails?
M
Matteo V. wrote:
On 4/20/07, Carmine M. [email protected] wrote:
installato la gem “composite_primary_keys” (0.8.2) ed ho sperimentato
- hanno diverso numero di componenti, sia utilizzando :options che
passando fisso il valore di una delle componenti, la ricerca in quella
con un numero maggiore
delle stesse, fallisce perch� alle componenti in pi� viene assegnato
irrimediabilmente “nil”.
Detto ci�, voi come fate? Rimetto tutto “a base di :options”?
Potresti forse creare delle view che siano pi� conformi allo stile di Rails?
Non posso alterare la struttura del DB legacy, anche perchè l’utilizzo
di
questo è un’opzione dell’applicazione che sto scrivendo (E-Commerce).
L’uso “normale” prevede tutto su Rails.
Inoltre, nella view comunque finirei con l’includere tutti i campi e
mi ritroverei punto e a capo.
On 4/20/07, Carmine M. [email protected] wrote:
Detto ci�, voi come fate? Rimetto tutto “a base di :options”?
Inoltre, nella view comunque finirei con l’includere tutti i campi e
mi ritroverei punto e a capo.
La view potrebbe avere una chiave primaria diversa, costruita come
composizione delle colonne della chiave primaria della tabella
originale.
M
–
Inoltre, nella view comunque finirei con l’includere tutti i campi e
mi ritroverei punto e a capo.
La view potrebbe avere una chiave primaria diversa, costruita come
composizione delle colonne della chiave primaria della tabella
originale.
Temo di non capire. Io ho bisogno della chiave completa quindi, di tutte
le colonne.
Facendo una view finirei con l’avere una “replica” della tabella da cui
è stata generata la view.
Cosa mi sfugge?
On 4/20/07, Carmine M. [email protected] wrote:
Facendo una view finirei con l’avere una “replica” della tabella da cui
è stata generata la view.
Cosa mi sfugge?
Voglio dire, se la tabella originale “pippo” ha una chiave composta da,
poniamo, nome e telefono, nella view aggiungi una nuova colonna
costruita
come concatenazione di nome e telefono. Tipo,
create view pippo_rails select concat(nome, telefono) as id, pippo.*
from
pippo
La view è senz’altro una replica della tabella orignale, che si avvicina
però alle convenzioni di Rails, perché ha una chiave primaria su una sola
colonna.
Che cosa succede quando fai un aggiornamento dei dati è un altro paio di
maniche 
M
–
Matteo V. wrote:
Cosa mi sfugge?
Voglio dire, se la tabella originale “pippo” ha una chiave composta da,
poniamo, nome e telefono, nella view aggiungi una nuova colonna
costruita
come concatenazione di nome e telefono. Tipo,
La view � senz’altro una replica della tabella orignale, che si avvicina
per� alle convenzioni di Rails, perch� ha una chiave primaria su una sola
colonna.
Ah ok. Ma a questo punto, ritengo sia meglio rimanere con :options
(soprattutto
se riesco a passargli dei parametri, si può?).
Non posso variare il DB legacy, indi niente aggiunta di View od altro.
Che cosa succede quando fai un aggiornamento dei dati � un altro paio di
maniche 
Fortunatamente (lassù qualcuno mi ama), non ho il problema di dover
aggiornare
il DB preesistente. Infatti, queste cose andranno fatte direttamente con
l’applicazione per cui è stato progettato.
In altri termini, l’applicazione Rails lo usa solo per visualizzare il
catalogo prodotti.
In un secondo momento, ho intenzione di integrare (plugin? altro?) una
gestione del catalogo slegata dal DB MS SQL.
Ho lasciato una richiesta di aiuto sul gruppo relativo a composite_keys,
attenderò al massimo un altro paio di giorni e, qualora la cosa non si
risolvesse, andrò avanti con :options. Poi chissÃ
Grazie 1000 per il tuo aiuto.