chl@jabber.at: grüss ihnen!
rist: tag
rist: und?
chl@jabber.at: hast wieder mal algodatvorlesung gehabt?
rist: na war schon länger nimmer, hab aber dienstags übung und mich heut kurzzeitig mit avl-trees beschäftigt
chl@jabber.at: das is lobenswert & vorrausschauend
rist: naja in der übung muss i einiges zum thema wissen
rist: und ausserdem sollt i die übung für datenmodellierung
rist: machen
rist: das is eher heftiger SQL kram
chl@jabber.at: um himmels willen!
rist: ja schon
rist: aber ich versteh nun sogar JOINT und GROUP BY
chl@jabber.at: JOINT?
chl@jabber.at: group by is ja durchaus essentiell
rist: JOIN
rist: meinte ich
chl@jabber.at: hehehehe
chl@jabber.at: studierst du grasql?
rist: ja genau
chl@jabber.at: SELECT weed from LEFT JOINT
rist: jaja
rist: und immer auf die transactions achten
rist: momentan mach tmich abe eher die mysql installation auf mac os x fertig
chl@jabber.at: für was installierst denn das?
rist: naja das hatte ich immer schon installiert aber momentan spinnts
rist: und ich wollt mein hop-abentuer von xml auf DB umstellen
chl@jabber.at: o!
chl@jabber.at: das is theoretisch gut
rist: wieso nur theoretisch?
chl@jabber.at: naja weil's praktisch ja probleme ggibt
rist: ja die gibts beim hop immer
chl@jabber.at: NA NA NA
chl@jabber.at: der lehni is nun auch ein hop-developer!
rist: jessas?
rist: was gibts neues von dem?
chl@jabber.at: ja er hat sich auf der hop-list angekündigt!
rist: aja!
chl@jabber.at: der hat die richtige wahl getroffen
rist: das haben wir doch alle
chl@jabber.at: naja was is jetzt mit deinen zopereien?
rist: noch nix
rist: so jeztt scheint mysql endlich zu laufen
rist: ja!
chl@jabber.at: ja gratulation!
chl@jabber.at: dann kann's ja jetzt richtig losgehen
rist: so nun ein kurzkurs zum thma hop und mysql bitte
chl@jabber.at: ja da macht man dies und jenes und das resultat is gut und schön
chl@jabber.at: ausführlicher?
rist: du bist mir ja eine große hilfe
chl@jabber.at: das hoffe ich doch!
rist: also für jeden prototyp brauch ich wohl eine table
chl@jabber.at: na im prinzip isses nicht schwer
chl@jabber.at: für den anfang ja
rist: und jede property eine prototypes eine spalte
chl@jabber.at: 1 stk. table, 1 stk. type.propertie
chl@jabber.at: s
chl@jabber.at: ja ganz genau!
rist: ok
rist: und da map ich dann jede property auf eine spalte oder reichts wenn sie gleichheissen
chl@jabber.at: wie die type.props ungefähr aussehen is eh dokumentiert (hoff ich)
chl@jabber.at: na, da schreibst
chl@jabber.at: propertyName = TABLE_NAME
chl@jabber.at: also firstName = USER_FIRST_NAME bspw.
chl@jabber.at: der nächste schritt sind dann object- und collection-mappings
chl@jabber.at: zB ...
chl@jabber.at: author = object (user)
chl@jabber.at: author.local = STORY_AUTHOR_ID
chl@jabber.at: author.foreign = ID
chl@jabber.at: is das eingängig und klar?
chl@jabber.at: lass mich bitte nicht vergessen heute matrix zu hören
rist: mal sehen
rist: d.h. ich sollt mal zuerst so was wie entity relationship kram aufzeichnen
chl@jabber.at: mhm, das is im prinzip genau das
rist: muss jeder prototyp irgendeine standard-spalte für die id haben?
chl@jabber.at: ja
rist: wie muss die heissen? was für ein typ?
rist: was für ein typ müssen spalten haben die als collection dienen?
chl@jabber.at: naja üblicherweise int
rist: aber in einer collection werden ja referenzen auf mehrere objekte gespeichert - oder?
chl@jabber.at: ids sind normalerweise die primary keys, und die sollten i.a. ints sein
chl@jabber.at: ja, aber dem relationalen modell entsprechend natürlich in einer anderen table
rist: also ich brauch für die collections schon eine zusätzliche table die den n:m kram macht?
chl@jabber.at: über den dir nun bekannten JOINT werden zwei tables gejoint, wobei .local und .foreign die join-kriterien definieren
chl@jabber.at: na na na na
rist: ok beispiel:
chl@jabber.at: ok
rist: ich hab eine tabelle in der ich alle möglichen sprachen aufzähl
chl@jabber.at: ok
rist: und ich hab eine tabelle mit den projekten und ich will ntürlich dass ein projekt mehere sprachen besitzen kann
rist: normallerweile mach ich mir da eine zusatztabelle PROJECT_SPRACHE
chl@jabber.at: ja, in diesem fall machst das da ebenso
rist: in der ich jeweils project_id und sprache_id in eine zeile schreib
chl@jabber.at: dann brauchst aber auch einen zusätzlichen prototypen
rist: für die sprachen?
chl@jabber.at: ProjectLanguageAssociation
chl@jabber.at: Project, Language, ProjectLanguageAssociation
rist: ok
rist: und der ProjectLanguageAssociation wird auf meine PROJECT_SPRACHE tabell gemappt?
chl@jabber.at: und die PLA-type.props müssten dann so aussehen:
chl@jabber.at: ja!
chl@jabber.at: _db = BLAH, _table = PROJECT_SPRACHE, _id = ID, project = object(Project), project.local = PROJECT_ID, project.foreign = ID, language = object(Language), language.local = LANGUAGE_ID, language.foreign = ID
chl@jabber.at: und die , san natürlich \ns
rist: aber kann ich das dann so irgendwie durch die gegend mappen, dass im hop dann ein PROJEKT prototyp eine property SPRACHEN hat und aus der kann die dann einfach auslesen
chl@jabber.at: genau
chl@jabber.at: in antville passiert das zB für die memberships
rist: ok die kapitel der einzelnen projekte, kann sich der hop die releations dann daraus bauen, dass ich einfach in jedes kapitel die ID des porjects reinschreib - oder braucht der hop dafür wieder eine eigene table
chl@jabber.at: das passiert genau so
rist: wie meinst? - also auch mit einer table für die relationen?
rist: weil an und für sich gehts das auch mit SELECT \* FROM kapitel WHERE PROJECT_ID = 17
chl@jabber.at: na, so wie du gemeint hast
rist: ok
chl@jabber.at: ohne zusätzliche table
chl@jabber.at: das is dann
chl@jabber.at: kapitel = collection(Kapitel), kapitel.local = ID, kapitel.foreign = PROJEKT_ID oder so ähnlich
rist: bzw. an und für sich reicht es wenn die kapitel children der projekte sind
chl@jabber.at: das kannst natürlich genauso machen
rist: der trick ist natüprlcih auch, dass kapitel auch children von kapiteln sein sollten
chl@jabber.at: o!
chl@jabber.at: naja an und für sich kein problem
chl@jabber.at: nur musst dann mit dem _parent aufpassen
rist: oje
rist: oje
rist: so ich glaub die db-table shab ich fertig
chl@jabber.at: ja hervorrragend
rist: könnt ich dir die schicken und dann die type.properties diskutieren?
chl@jabber.at: ja natürlich
rist: mal sehen ob das jabber packt:
rist: #
# Table structure for table `chapter`
#
CREATE TABLE chapter (
ID int(11) NOT NULL default '0',
NAME varchar(64) NOT NULL default '',
COMMENT varchar(255) NOT NULL default '',
SCREENSHOT varchar(65) NOT NULL default '',
PRIMARY KEY (ID),
UNIQUE KEY SCREENSHOT (SCREENSHOT),
UNIQUE KEY NAME (NAME)
) TYPE=MyISAM;
# --------------------------------------------------------
#
# Table structure for table `element`
#
CREATE TABLE element (
ID int(11) NOT NULL default '0',
NAME varchar(64) NOT NULL default '',
COMMENT varchar(12 NOT NULL default '',
PRIMARY KEY (ID)
) TYPE=MyISAM;
# --------------------------------------------------------
#
# Table structure for table `languages`
#
CREATE TABLE languages (
ID int(11) NOT NULL default '0',
ISO char(2) NOT NULL default '',
NAME varchar(32) NOT NULL default '',
PRIMARY KEY (ID),
UNIQUE KEY ISO (ISO,NAME)
) TYPE=MyISAM;
# --------------------------------------------------------
#
# Table structure for table `project_languages`
#
CREATE TABLE project_languages (
PROJECT_ID int(11) NOT NULL default '0',
LANGUAGE_ID int(11) NOT NULL default '0'
) TYPE=MyISAM;
# --------------------------------------------------------
#
# Table structure for table `projects`
#
CREATE TABLE projects (
ID int(11) NOT NULL default '0',
NAME varchar(32) NOT NULL default '',
COMMENTS varchar(255) NOT NULL default '',
PRIMARY KEY (ID),
UNIQUE KEY NAME (NAME)
) TYPE=MyISAM;
# --------------------------------------------------------
#
# Table structure for table `translation`
#
CREATE TABLE translation (
ID int(11) NOT NULL default '0',
NAME varchar(64) NOT NULL default '',
CONTENT blob NOT NULL,
OLDER_VERSION int(11) NOT NULL default '0',
PRIMARY KEY (ID)
) TYPE=MyISAM;
rist: super - der wandelt manches in emoticons um
chl@jabber.at: project_languages braucht auch eine id
chl@jabber.at: das hab ich glücklicherweise ausgeschalten
rist: ok - aber an und für sich is doch jede zeile in project_langauges eindeutig?
chl@jabber.at: das nutzt dem hop nix
rist: ok
chl@jabber.at: ob der hop mit blobs eine gaudi hat is auch fraglich
chl@jabber.at: aber ausprobierenswert
rist: hab grad weisheiten von dir aus dem ajhre 2000 gefunden -
http://piefke.editthispag…
rist: aber mysql unterstütz nur 255 chars in VARCHAR
chl@jabber.at: herrje!
chl@jabber.at: naja dafür gibt's ja noch tausende TEXT-varianten
rist: stimmt
rist: ok dann nimm ich text - das is 2^16
chl@jabber.at: das is gar nicht wenig!
rist: durchasu reichlich - aber 256 kann einfach zuwenig sein
chl@jabber.at: allerdings
chl@jabber.at: obwohl vanilla 0.6 wahrscheinlich die snip-länge auf 32 beschränken wird
chl@jabber.at: und den snip-namen auf 8.3
rist: denn die wahnsinnigen sind durchaus fähig laengere texte zu verfassen
rist: das is schalu und begruessenswert
chl@jabber.at: das denk ich mir auch
chl@jabber.at: vor allem wenn man bedenkt, wie knapp in letzter zeit speicherplatz geworden ist
rist: eben!
rist: vor allem wenn man kommerzielles vanilla hsoting denkt
chl@jabber.at: was hältst von einem einsteigerpaket - 7 snips zu 32 zeichen?
rist: das sind ja 224 characters!
chl@jabber.at: VanillaPro würde dann 14 snips bieten, also mehr als genug, um _zwei wochen_ voller information unterzubringen
rist: oder die komplette synerge website
chl@jabber.at: \
ROFL\
chl@jabber.at: böse, böse
rist: ja schon
rist: hast du schon visionen zu den type.proerpties?
chl@jabber.at: ja soll ich sie dir schreiben oder was?
rist: das wär wunderbar
chl@jabber.at: na na na
chl@jabber.at: so lernst ja nix
rist: das stimmt natürlich a wieder
chl@jabber.at: ich würd vorschlagen du schreibst jeweils eine und dann werd ich mehr oder weniger hilfreich kommentieren
rist: ok - ich fang mal einfach an
chl@jabber.at: gut so
rist: type.properties für "languages"
rist: _table = languages
_id = ID
iso = ISO
name = NAME
rist: ok?
rist: muss das "_db" in jede type-property??
chl@jabber.at: ja!
rist: ok
rist: passen die properties für "languages"?
chl@jabber.at: mal sehen, ein _parent dürftest noch brauchen
rist: muss das auch in die DB?
chl@jabber.at: _parent = project_languages.language
chl@jabber.at: na!
chl@jabber.at: das braucht der hop, damit er die hrefs richtig generieren kann
chl@jabber.at: _parent = [prototype-name].[attr-name]
rist: das "project_languages" is das die table oder der hop-prototype?
chl@jabber.at: proto
rist: ok
rist: (der hesitt bei mir projectLanguageAssociation)
rist: ok - vielleicht sollt ich erstmal auch die db.properties richten
rist: muss ich das im helma verzeichnis editieren?
chl@jabber.at: kannst das oder auch im app-dir eines haben
rist: also ins translate-verzeichnis kopieren
rist: die url versteh ich nit ganz
rist: jdbc:mysql://db.domain.com/space
rist: domain.com ersetz ich durch localhost
rist: db durch "translate"
rist: was mach im mit space
chl@jabber.at: na na na
rist: ja ja ja
chl@jabber.at: jdbc:mysql://localhost/translate
chl@jabber.at: der placeholder is eher deppert
rist: denk ich mir
chl@jabber.at: kannst dich gleich auf der hop-list beschweren
rist: ja sofort
rist: das type.proeprty für projectLanguageAssociation
rist: _db = translate
_table = project_languages
_id = ID
project = object(project)
project.local = PROJECT_ID
project.foreign = ID
language = object(language)
language.local = LANGUAGE_ID
language.foreign = ID
rist: ok?
chl@jabber.at: sieht gut aus
chl@jabber.at: bis auf das fehlende _parent
rist: was sollt der wert dafür sein`?
chl@jabber.at: wie heisst der prototyp vom project?
chl@jabber.at: etwa gar ... project?
rist: project
chl@jabber.at: wow.
rist: jka schon
chl@jabber.at: ich könnt mich als hellseher versuchen
rist: und dei DB anbindung funktioniert !
chl@jabber.at: JA HERVORRAGEND!!!
chl@jabber.at: ich werd mal ö1 suchen
rist: bringt zwar errors aber sieht trotzdm gut aus
rist: da läuft grad contra
chl@jabber.at: gibt
chl@jabber.at: 's da irgendwo eine frequenztabelle?
rist: http://193.187.212.11/ORF/
rist: wow - eine GIS app
chl@jabber.at: begeisternd
rist: durchaus
chl@jabber.at: gut, die frequenz wäre gefunden
chl@jabber.at: wie soll das attribut für die association heissen?
rist: languages
rist: also du meinst die property von projects in der die sprachen gesammelt/zugeordnet werden
chl@jabber.at: ja!
rist: ok projects.languages
chl@jabber.at: also _parent = project.languages
rist: ok
rist: die type.properties für "prjects"
rist: _db = translate
_table = projects
_id = ID
_parent = projects
name = NAME
comments = COMMENTS
rist: muss da die sche mit den srpachen auch noch rein?
chl@jabber.at: der prototyp heisst project ohne s oder?
rist: ja
chl@jabber.at: naja wo gedenkst die projects wirklich reinzuhängen?
chl@jabber.at: in das root-objekt?
rist: ja die sind children des roots
chl@jabber.at: dann _parent = root
rist: so einfach?
chl@jabber.at: ja
chl@jabber.at: is das nicht unglaublich?
rist: naja
chl@jabber.at: die ö1-leute sollten mal für weniger hintergrundgeräusche in deren interviews sorgen
rist: \
LOL\
chl@jabber.at: vielleicht indem sie diese nicht auf baustellen veranstalten
rist: gute idee
rist: kleine änderung - die table "chapter" heiss nun "container"
rist: type.properties von container:
rist: _db = translate
_table = container
_id = ID
_parent = project
name = NAME
comments = COMMENTS
screenshot = SCREENSHOT
_extends = project
rist: ich bin mir nti sicher in punkto _parent insbesondere wegen dem _extends
chl@jabber.at: für was is das chapter überhaupt gut?
rist: um die dinger zu sammeln
rist: also du hast ein project - eine CD-ROM
rist: die besteht aus einzelnen movies und die wieder aus einzelnen screens
chl@jabber.at: ja
chl@jabber.at: also aus elements
rist: und auf den einzlenen screens finden sich dann die "elements" die übersetzt werden
chl@jabber.at: aber nicht wirklich aus chapters
chl@jabber.at: oder?
chl@jabber.at: o!
rist: na deswegen nenn ich es lieber container als chapter
rist: und jedes element besitzt dann einzelne translations - für jede sprache eine
chl@jabber.at: chapters sind nicht hierarchisch?
rist: und jede translation verweist auf ihre vorversion (um versioning zu ermöglichen)
rist: doch
chl@jabber.at: elements aber nicht
rist: ein project besthet aus containern
chl@jabber.at: so ich muss jetzt kurz konzentriert matrix hören
rist: ok
rist: ich fass in der zwischenzeit das datenmodell nochmnals zusammen:
rist: ein "project" entspricht einem realem Projekt.
ein element entspricht einem Text-element auf irgendeinem Screen.
ein Projekt besteht aus mehreren Containern - z.b. der Container "Corporate Information".
"Corporate Information" informiert auf verschiedenen Screens zu verschieden Themen etwa "Human Resources", "Mission Statement" - der Container "Corporate Information" besitzt somit 2 Sub-Container.
Die beiden Subcontainer sind auf der CD-ROM zum Beispiel je ein Screen und deshalb besitzt dann jeder der Container diverse Elemente etwa "Headline links oben", "Fliesstext"
Die Container sind dafür da die Elemente hierarchisch zu organisieren und die Navigation für den Übersetzer zu erleichtern - so sollte jeder einzelne Screen durch einen Container abgebildet werden (z.b. hat jeder Container eine "Screenshot"-Property)
chl@jabber.at: das futurezone-forum flutet wieder mal über
rist: ja natüröoch
chl@jabber.at: der sendeplatz is auch ein wahn
rist: schlimmer war DI um 8:00
rist: wär
rist: wäre (konjunktiv)
chl@jabber.at: oder donnerstag um 11:15
chl@jabber.at: oder allgemein ö1
chl@jabber.at: gut hingegen wär montag, 7:00 auf ö3
rist: na damit hab ich kein problem
chl@jabber.at: oder samstag 19:00 auf fm4
rist: was is da normalerweis - die fm4charts - oder?
rist: is meine glorreiche datenstruktur halbwegs verständlich
chl@jabber.at: glaub schon
rist: ok
chl@jabber.at: die datenstruktur is durchaus verständlich
rist: dann zurück zum type.properties für "container"
rist: _db = translate
_table = container
_id = ID
_parent = project
name = NAME
comments = COMMENTS
screenshot = SCREENSHOT
_extends = project
chl@jabber.at: aber warum soll ein container ein project extenden?
rist: wie is das mit dem _parent und dem _extends
rist: passt das?
chl@jabber.at: naja vergiss _extends einstweilen
chl@jabber.at: für das bist du noch zu jung
rist: das parent eines containers kann nämlich sehr wohl ein container sein
chl@jabber.at: EBEN
rist: braiuch das _extend aber für irgendeine andere schweinerei
rist: die radiokusnt auf ö1 is aber auch grad ein hit
chl@jabber.at: also: _parent = project, container
chl@jabber.at: lohnt es sich, den weiten weg zum radio zu gehen und wieder aufzuschalten?
rist: ja sehr!
chl@jabber.at: ja dann sec
chl@jabber.at: is das nicht schon vorbei?
chl@jabber.at: oder von was hat der typ jetzt gesprochen?
rist: doch da is nun kunst zum thema isländische heldensagen
chl@jabber.at: ah das is ok
rist: type.property von element:
rist: _db = translate
_table = element
_id = ID
_parent = container
name = NAME
comments = COMMENT
rist: was ich jetzt will ist, dass die children von element vom typ "translation" sind
chl@jabber.at: ok
rist: wie geht das?
chl@jabber.at: _children = collection(translation)
chl@jabber.at: und der ganze foreign/local-zimbori
rist: so?
rist: _children.local = ID
_children.foreign = ID
rist: und bracuh ich dfür wieder eine eigene table/spalte (oder hab ich das schon gefragt?)
chl@jabber.at: na so dürft das nix werden
rist: oje?
chl@jabber.at: naja die translation muss schon auch irgendwo vermerken, zu welchem element sie gehört
chl@jabber.at: also, neue spalte ELEMENT_ID in translation
chl@jabber.at: und dann _children.local = ID, _children.foreign = ELEMENT_ID
rist: ok
rist: tpye.proeprties für translation:
rist: _db = translate
_table = translation
_id = ID
content = CONTENT
precessor = OLDER_VERSION
rist: passt das?
chl@jabber.at: sorry, war grad weg
rist: kein problem
chl@jabber.at: naja _parent fehlt
rist: aja!
chl@jabber.at: und predecessor sollte das heissen
chl@jabber.at: und wohl eher ein object sein, oder?
rist: ja schon - wie geht das?
rist: _parent = element
chl@jabber.at: predecessor = object(translation)
chl@jabber.at: predecessor.local = OLDER_VERSION_ID
chl@jabber.at: predecessor.foreign = ID
chl@jabber.at: parent = element, translation.predecessor
rist: und "predecessor = OLDER_VERSION" raus - oder?
chl@jabber.at: _
chl@jabber.at: ja natürlich
chl@jabber.at: und OLDER_VERSION würd ich in OLDER_VERSION_ID umbenennen
rist: das is klar
rist: d.h. ich hab nun all mein type.properties und die DB anbindugn geht auch - ja wunderbar!!
rist: ich danke sehr und werd nun beruhigt schlafen gehen
chl@jabber.at: ja hoffentlich geht das dann auch alles
chl@jabber.at: aber das wird ja bald festzustellen sein
chl@jabber.at: gerne! & eine gute nacht