i'm modelling type information of relational database. build following graph:
the vertices tables.
an edge exists table table b every column in foreign key b.
this initial data have building graph.
newtype tablename = tablename t.text newtype colname = colname t.text newtype coltype = coltype t.text type dbinfo = h.hashmap tablename tableinfo type tableinfo = h.hashmap colname colinfo data colinfo = cisimple coltype -- forms basis building graph | cifkey coltype tablename -- col type, referenced table getdbinfo :: io (dbinfo) these types of graph structure i'm expecting.
data safecolinfo = scisimple coltype -- captures edge between 2 tables | scifkey coltype safetableinfo type safetableinfo = h.hashmap tablename safecolinfo type safedbinfo = .. i write function :
convdbinfo :: dbinfo -> either string safedbinfo convdbinfo should build above graph. information t in foreign key (cifkey ctype t) can found looking t in dbinfo. if not found, input data inconsistent , error.
this straightforward in imperative language references. however, can't think of way solve in haskell. understand, looks fit 'tying knot' paradigm, can't seem wrap head around it. how write function?
we can tie knot following way:
convdbinfo :: dbinfo -> safedbinfo convdbinfo dbi = safedbi safedbi = h.map (h.map go) dbi go (cifkey colname tblname) = scifkey colname $ safedbi h.! tblname go (cisimple colname) = scisimple colname we safedbi mapping on column entries in input. important point tables safedbi in definition of go, tables in scifkey-s resulting hashmap.
example:
foo :: dbinfo foo = h.fromlist [ ("table1", h.fromlist [ ("col1", cifkey "a" "table2") ]), ("table2", h.fromlist [ ("col2", cifkey "b" "table1") ]) ] bar = convdbinfo foo scifkey _ tbl2 = (bar h.! "table1") h.! "col1" scifkey name _ = tbl2 h.! "col2" -- name == "b" note though knotty data structures inconvenient use, because indistinguishable lazy infinite structures, have give thought when we'd print, serialize or compare them. of time explicitly keyed graphs easier use, , not worse performance wise.
Comments
Post a Comment