ActiveRecord er et fint værktøj til database administration. Simpelt vedligehold eller hele migrationer af data på en enkelt eller flere databaser fra et Ruby script med ActiveRecord model objekter. Supercool! I dette tilfælde vil jeg hente domain objekter ud fra en database og fodre dem til en anden database instans og kunne bruge alle de fede features fra active record. Konfiguration Første punkt er en yaml fil med database konfiguration på de forskellige databaser. I dette tilfælde operere jeg på active record objecter fra to forskellige typer af database. <pre> database_from: adapter: mysql # encoding: utf8 database: intra_production username: **** password: **** host: thor database_to: adapter: sqlite3 database: db/production.sqlite3 timeout: 5000 </pre> $config = YAML.load_file(File.join(File.dirname(__FILE__), 'database.yml')) </pre> Den nederste linje læser yaml konfigurationsfilen ind i ruby. Herfra kan direkte slå op i yaml strukturen. Database forbindelse <pre> class DBFrom < ActiveRecord::Base establish_connection $config['database_From'] end class DBTo < ActiveRecord::Base establish_connection $config['database_To'] end </pre> Ruby's Mixin skal hjælpe med med at bruge de korrekte modelnavne. Jeg indkapsler modellerne i hver deres mixin modul. Det er min Separation of concern, nu kan jeg notere mine object på namespace eller prefix. Nu mangler blot klassernedefinitionerne for de modeller der skal arbejdes med men det er nemt med AC. På grund af Ruby's metaprogrammering egenskaber er der ingen metoder. Kun relationerne skal specificeres. <pre> module From class Post < DBFrom has_many :comments end class Comment < DBFrom belongs_to :posts end end module To ... end </pre> I dette skal jeg flytte data og har derfor næsten samme skema i begge databaser men samme metoder kunne også bruges mellem development og produktion på samme skema. <pre> posts = From::Post.find(:all, :order => "created_at") posts.each do |post| new_post = To::Post.new new_post.title = post.title new_post.save end </pre> Nu har man jo naturligvis relationer til andre tabeller i databasen og de skal måske også kopieres over i den nye instans. Når jeg henter en post op er der måske nogle comments med og alle associationer skal loades samtidig. Derpå er det blot at mixin det nye objekt og bygge de associationer som hører til. Når man kalder objektes save metode gemmes den nye record i den anden database. 11 2008-01-09T22:17:12Z 89 89 false 8 2008-01-10T04:31:02Z Midt i et foredrag kom jeg i tvivl om hvilken form for join model der er den bedste i Rails. Svaret er jo nok afhængig af løsningen og den enkelts krav til information på selve relationen. Hidtil har det været god metodik at man skal holde sine join tabeller rene. Det betyder altså at der ikke bør være anden information end primær nøgler der relatere de to mange til mange tableller. I Rails findes der to løsninger på mange til mange relationen. Den ene er en simple (habtm) implementation som kun kræver en ekstra database join tabel. Den anden løsning(through association) kræver også en ekstra tabel men har et model objekt og ekstra attributter på relationen. Simple Associations(HABTM) Tabel Join <pre> create_table :posts_tags, :id => false do |t| t.column :post_id, :integer t.column :tag_id, :integer end </pre> Model <pre> class Post < ActiveRecord::Base has_and_belongs_to_many :tags end class Tag < ActiveRecord::Base has_and_belongs_to_many :posts end </pre> Her har vi altså to model objekter som har en many-to-many relation mellem posts og tags. Det er en konvention i Rails at join tabellen bliver kaldt posts_tags. Man kan ikke lægge ekstra information på relationen og tabellen kan ikke indenholde primær nøgle. Denne model er at fortrække hvis løsningen ikke kræver mere information omkring selve relationen. <pre> @post.tags << Tag.find ”Ruby” << Tag.find ”Java” </pre> Denne løsning er enkelt at bruge og sætte op. Bemærk at der ikke er en model for relationen. Rich Associations(through association) I denne variation kræver AC en primær nøgle på relationen samt et model objekt. I dette tilfælde kan det betale sig at finde på et godt navn til relationen. I den simple model skulle vi blot navngive tabellen udfra de to tabeller som skal relateres men nu skal vi bruge et godt sigene navn til den model som indkapsler relationen. Tabel Join <pre> create_table :tagszations do |t| t.column :post_id, :integer t.column :tag_id, :integer t.column :created_at, :datetime end </pre> Model <pre> class Tagszation < ActiveRecord::Base belongs_to :post belongs_to :tag end class Tag < ActiveRecord::Base has_many :tagszation has_many :posts, :through => :tagszation end class Post < ActiveRecord::Base has_many :tagszation has_many :tags, :through => :tagszation, :select => "DISTINCT tags.*" end </pre> Denne metode giver mere fleksibilitet på selve relationen og er nemt at sætte op for den simple løsning men kan snyde lidt når man går fra HABTM til through association. <pre> post = Post.find(1) post.tags.size # => 4 ruby = Tag.find(2) tagz = Tagszation.new(:post => post, :tag => ruby) post.save post.tags.size # => 4 post.tags(true).size # => 5 </pre> Ups. Push metoden virker ikke for has_many :through relation. Hvorfor? Rails API siger at metoden tilføjer en samling attributter til objektet i relationen. Denne relation virker som et array af relateret objekter men indeholder ekstra hjælpe metoder som gør livet værd at leve. Faktisk er dette ikke et array men en instans af AssociationCollection som igen er en supklasse af AssociationProxy. Dette er klasser som følger Proxy pattern. Klassen fungerer som front objekt for at give ekstra adfærd til det bagvedliggende objekt. AssociationProxy uddelegere til et enkelt model objekt og for has_one eller belongs_to. AssociationCollection delegere et Array af model objekter. De delegerede metoder er med i class så hvis du spore objektet hvilken type vil det sige array selvom det ikke er tilfældet. Funny Her er en sammenlinning af de to typer i tabelform. Tak til has_many :through || Association| has_and_belongs_to_many | has_many :through || || AKA | habtm | through association || || Structure | Join Table | Join Model || || Primary Key | no | yes || || Rich Association | no | yes || || Proxy Collection | yes | no || || Distinct Selection | yes | no yes || || Self-Referential | yes | yes || || Eager Loading | yes | yes || || Polymorphism | no | yes || || N-way Joins | no | yes || Structure has_and_belongs_to_many benytter en simple join table hvor hver række blot er to fremme nøgler. Der findes ikke et model objekt i rails og man tilgår ikke denne tabel direkte Primary Key Join tables har ikke en primærnøgle. Nogle forsøger sig med at generer en nøgle ud fra et par fremmed nøgler men det er noget crap. Join models derimod har en primærnøgle ligesom alle modeller har et telefonnummer. Det betyder at du kan manipolere tabellen direkte. Rich Association Hvis du behøver information på relations tabellen må du bruge en join model. Proxy Collection En fordel ved habtm er at den skabte relation er en såkaldt proxy collection. Det betyder mulighed for oprette elementer i join tabellen med relationens << (push) metode på samme måde som med has_many relationer. Fordi join model har ekstra attributter på relationen bliver det mere kompliceret at oprette dem automatisk. Distinct Selection Nogle gange kan en join table, eller model have flere referencer mellem de samme rækker. Hvis man ikke vil ha alle men blot en kan man bruge :unique. Dette ville svare til at bruge DISTINCT i sql. Forsørgelsen returner uden duplikater. Forskellen er om duplikater skal fjernes i databasen eller i Ruby. Self-Referential Begge modeller kan referere til sig selv. Fx kan man i habtm bruge :foreign_key og :association_foreign_key. Eager Loading Begge modeller supporter eager loading af relaterede objekter med :include. Polymorphism Join models og through relationer kan arbejde med polymorfe model typer. N-way Joins En habtm relation kan kun joine to modeller men through modellen kan joine ligeså mange du vil. Men pas på, det bliver let kompliceret. 11 2007-12-13T08:34:00Z 86 86 false 8 2008-01-03T13:32:04Z Hvis din objektmodel er replikeret over flere VM'er, så er sandsynligheden for at alle crasher samtidigt, lige så lille som at DB's diske crasher. Så kan man rent faktisk arbejde med crash-tolerant memory og antage at heap'en aldrig slettes. Det fjerner hele behovet for et data-access layer, for applikationens model er jo crash-resilient. Det betyder at man kan droppe databasen og bruge memory i stedet. Halvdelen af alle framevorks i Java handler om O/R mappingsproblemet og der er skrevet indtil flere design patterns som attakere netop dette problem som fx valuebean(VB) og datatransferobject(DTO) der er strukturelle mønster. Enlig er det en ret enkelt og ligetil proces. Problemet er at det er trivielt og at vi i mange år skrevet tusind af klasser som gør præsis det samme. En såkaldt serverside programmør lever af at mappe tabeller og relationer i databasen til en objektmodel til trods trods for at tabeller og objekter er to vidt forskellige konstruktioner. Firkantede database tabeller passer ikke lige over til et rent objektorienteret paradigme. Et par gode kolleger fra Javahouse tiden og jeg selv, inviterede Owen Taylor til Danmark for at tale i et par banker og i cybercomgroup headquarter. Owen er specialist i Giga Spaces teknologien. Det helt essentielle ved Spaces er hastighed og skalerbarhed. Men i tilgift får man en sjov afledt effekt. Et typisk forløb er at man preloader en mængte data fra databasen om morgenen hvorefter arbejdet begynder. Efter arbejdet kan man evt. gemmer nye data. Resten af tiden benyttes kun memory. Alle objekter er persistente og replikerede. Eneste logiske grund til at opdatere databasen er at interaktion med legacy systemer. Selve spaces er aldrig nede. Den helt store fordel er at man kan fjerne hele databasen og alle de gamle problemer med O/R mapping og hele dataaccess layer i den gammeldags software model. Der er fortaget undersøgelser som viser at backend programmering(O/R mapping) tager ca. 60 procent af alt udviklingstid. 13 2007-08-14T00:12:00Z 59 59 false 8 2008-04-08T07:29:18Z