Nom de la clé étrangère dans les associations DataMapper

Question

Je travaille actuellement sur une nouvelle application basée sur une base de données existante, en utilisant DataMapper pour l'accès aux données. Cependant, ses conventions lorsqu'il traite des clés étrangères ne sont pas ce que la base de données utilise.

Exemple:

class Invoice 
    include DataMapper::Resource 

    storage_names[:default] = 'invoices' 

    property :id, Serial 
    # ... more properties ... 

    has n, :items 
end 

class Item 
    include DataMapper::Resource 

    storage_names[:default] = 'invoiceItems' 

    property :id, Serial 
    # ... more properties ... 

    belongs_to :invoice # this should use 'invoiceId' instead of 'invoice_id' 
end 

Est-il possible que je peux obtenir la clé étrangère utilisée par DataMapper être « InvoiceID » plutôt que le « invoice_id », il essaie d'utiliser au moment (comme l'indique le commentaire au dessus)? Je sais que cela peut être fait avec des champs normaux en ajoutant :field => 'fieldName' mais je n'ai trouvé aucune telle manière pour les associations.

Answer 1

Et pas pour la première fois, j'ai trouvé la réponse à ma propre question grâce à very helpful blog entry de Jan De Poorter.

Il est nécessaire d'ajuster les conventions lorsque vous traitez des noms de champ afin qu'il utilise simplement le nom du symbole plutôt que d'utiliser son intelligence intégrée en ce qui concerne les traits de soulignement.

repository(:default).adapter.field_naming_convention = lambda { |value| value.name.to_s } 

Le nom de clé étrangère peut alors être spécifié comme suit:

class Invoice 
    # bla bla... 
    has n, :items, :child_key => [:invoiceId] 
end 

class Item 
    # bla bla... 
    belongs_to :invoice, :child_key => [:invoiceId] 
end 

Il convient de noter (comme indiqué ci-dessus) que le nom de la clé doit être spécifiée sur les deux côtés de la relation (qui Je trouve un peu étrange, mais bon). Espérons que cela aidera quelqu'un d'autre qui se retrouve à poser la même question. Merci à Jan De Poorter pour la réponse.