Forum: Italian Ruby user group Legacy DB e composite keys

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Carmine M. (Guest)
on 2007-04-20 09:09
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
Matteo V. (Guest)
on 2007-04-20 16:31
(Received via mailing list)
On 4/20/07, Carmine M. <removed_email_address@domain.invalid> 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
Carmine M. (Guest)
on 2007-04-20 16:37
Matteo V. wrote:
> On 4/20/07, Carmine M. <removed_email_address@domain.invalid> 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.
Matteo V. (Guest)
on 2007-04-20 16:39
(Received via mailing list)
On 4/20/07, Carmine M. <removed_email_address@domain.invalid> 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

--
Carmine M. (Guest)
on 2007-04-20 18:54
>> 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?
Matteo V. (Guest)
on 2007-04-21 20:09
(Received via mailing list)
On 4/20/07, Carmine M. <removed_email_address@domain.invalid> 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

--
Carmine M. (Guest)
on 2007-04-22 13:53
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.
This topic is locked and can not be replied to.