[ANN] db4o - database for objects - v. 2.7 [prOsT]
Carl Rosenberger
wir haben ein neues Release draussen. Ich freue mich immer
ganz besonders über Feedback von hier, von Leuten, die ich
schon länger kenne. Aus manchen werden bestimmt langjährige
Freunde werden. (wenn sie denn dann auch mal Salami und Wein
mitbringen, anstatt immer nur die Bösen in der db4o Newsgroup
news://news.db4odev.com/db4o.users zu belehren. Dank!)
Wer db4o schon kennt:
- ObjectServer#openClient() erlaubt jetzt auch direkte
Client/Server Transaktionen ohne Umweg über einen Port.
- Das Servlet-Interface ist aus der Jar draussen, dafür aber
als Source verfügbar.
- Aufbauend auf ObjectServer#openClient() gibt es jetzt auch
einen Servlet-Modus, in der jede Session ein "Client" ist,
mit eigenem Memory- und Referenzraum und eigener Transaktion.
- Es gibt jetzt einzelne Jar Versionen für alle üblichen JDKs:
1.1, 1.2, 1.3. und 1.4. Dann klappts endlich auch ohne
Dekompilieren mit Websphere Studio Device Developer.
- Getestet wurde die Lauffähigkeit mit einer ganzen Reihe von
exotischen VMs, unter anderem Symbian EPOC, Savaje, PersonalJava
und IBMs J9 foundation profile.
Wer sich wundert, warum so wenig Funktionalität so lange gedauert
hat: Es gibt jetzt eine komplett equivalente C# Version für alle
.NET Sprachen, die unter anderem auch auf dem CompactFramework
(PocketPC, WindowsMobile 2003) läuft. Das heisst aber nicht, daß
die Java-Version in Zukunft eine geringere Priorität hat.
Entwickelt wird weiterhin in Java, der C# Code wird mit einem
eigens dafür gebauten Converter erzeugt.
Wer db4o noch gar nicht kennt:
db4o ist eine Client/Server Objektdatenbank. Als Funktionalität
bietet sie unter anderem ACID Transaktionen, Query-By-Example,
das S.O.D.A. Objekt Abfrage API, WeakReference Objekt-Identitäts-
Management, und automatische Klassen-Schema-Erkennung. db4o wird
als 250kB .Jar ausgeliefert.
Der entscheidende Vorteil aus der Verwendung von db4o ensteht aus
der Einfachheit:
Eine Zeile Programmiercode speichert jedes Objekt.
Aus der Einfachheit von db4o lassen sich direkt Vorteile bei der Anwendungsentwicklung ableiten:
- kürzere Entwicklungszeit, damit schnellere Marktreife
- geringere Entwicklungskosten
- bestmögliche Refakturierbarkeit und Wartung
- schnellere Ausführungsgeschwindigkeit
Eine db4o Evaluierungsversion ist auf der db4o Website verfügbar:
http://www.db4o.com
Viel Spaß beim Ausprobieren!
10 Minuten sollten eigentlich reichen, um das Prinzip zu
verstehen:
- db4o.jar einbinden.
- Minimalstcode ausprobieren:
import com.db4o.*;
import com.db4o.query.*;
public class HelloDb4o {
public String name;
public HelloDb4o() {}
public HelloDb4o(String name) {this.name = name;}
public static void main(String[] args) {
ObjectContainer objectContainer = Db4o.openFile("HelloDb4o.yap");
objectContainer.set(new HelloDb4o("hello"));
Query q = objectContainer.query();
q.constrain(HelloDb4o.class);
ObjectSet objectSet = q.execute();
while (objectSet.hasNext()) {
System.out.println(objectSet.next());
}
objectContainer.close();
}
public String toString() {return "HelloDb4o name:" + name;}
}
Feedback, Tipps und Kritik sind erwünscht!
Viele Grüße,
Carl
--
Carl Rosenberger
db4o - database for objects - http://www.db4o.com
Andree Große
> Hallo ihr alle,
>
> wir haben ein neues Release draussen. Ich freue mich immer
> ganz besonders über Feedback von hier, von Leuten, die ich
> schon länger kenne. Aus manchen werden bestimmt langjährige
> Freunde werden. (wenn sie denn dann auch mal Salami und Wein
> mitbringen, anstatt immer nur die Bösen in der db4o Newsgroup
> news://news.db4odev.com/db4o.users zu belehren. Dank!)
Hi Carl,
nachdem du nun so oft db4o hier publiziert hast, dachte ich
mir, sieh es dir doch mal an und probier es aus. Da ich bisher
ausschließlich mit SQL-Datenbanken arbeite war mein erster
Gedanke natürlich der Import vorhandener Datenbankschemas.
Es ist Grundvoraussetzung beim Umstieg von System A nach B
dafür zu sorgen, dass vorhandene Datenbestände migriert werden
können. Doch das funktioniert bei db4o überhaupt nicht.
Mein 1.Versuch ging auf Oracle - das Resultat ernüchternd.
1.Ganz offensichtlich übergebt ihr beim Auslesen der User-Tables
nicht den Schemanamen. Es wird versucht Tabellen zu importieren,
die gar nicht zum Schema des verbundenen Nutzers gehören.
Und ich hab die Stelle auch gefunden:
Klasse: com.db4o.sql.SQL.java
static List4 getTables (Connection a_connection, boolean a_getFields) {
List4 col = new List4();
try {
DatabaseMetaData meta = a_connection.getMetaData();
String[] types = {
"TABLE"
};
ResultSet rs = meta.getTables(null, null, null, types);
^^^^
Richtig sollte es lauten: meta.getTables(null, schema, "%", types);
Bei Oracle entspricht das z.B. dem User-Name.
2.Ihr scheint zu vergessen, Statement-Objekte unmittelbar wieder
zu schließen. Es erscheint die dafür typische Fehlermeldung:
ORA-01000: Maximale Anzahl offener Cursor überschritten
Und tschüß...
Der 2.te Versuch ging gegen InstantDB:
Hier erscheint beim Versuch Java-Quellen zu erzeugen die folgende
Fehlermeldung:
Making Java: veranstaltungen
File.copy failed.
java.io.FileNotFoundException:
D:\java\opensource\db4o\db4o2.7\bin\com\db4o\jgen\JClass.jgt
(Das System kann die angegebene Datei nicht finden)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.<init>(Unknown Source)
at com.db4o.lib.File4.copy(File4.java:40)
at com.db4o.lib.File4.copy(File4.java:66)
at com.db4o.jgen.JClass.write(JClass.java:109)
at com.db4o.sql.SqlTable.createJavaFile(SqlTable.java:78)
at com.db4o.sql.SqlImport.createJavaFiles(SqlImport.java:90)
at com.db4o.sql.SqlImport.main(SqlImport.java:44)
SQLImport raises Exception:
null
Und wieder tschüß...
Zusätzlich muß ich sagen, dass mir eure Philosophie in keiner
Weise zusagt, was die grobe Verletzung eines der wesentlichen
Grundprinzipien der oo Programmierung verletzt, nämlich die
Datenkapselung. Alle Attribute müssen public sein, um per
Reflection darauf zugreifen zu können. Genau so gut hätte die
Forderung genügt, alle Attribute müssen öffentliche getter-/setter-
Methoden haben a la get<AttributeName>()/set<AttributeName>().
Alles in allem eine herbe Enttäuschung, die nicht dazu beiträgt,
objekt-orientierte DB's aus ihrem Nieschendasein zu verhelfen.
Und dafür in irgendeiner Form Geld zu verlagen, ist so lange
unseriös, solange ihr offenbar noch nichtmal eure eigenen
Beispiele auf Herz und Nieren testet. Wo bitte schön kommt z.B.
das Package javax.print.attribute.standard her?
(in der Klasse: com.db4o.samples.translators.TDateTimeAtCreation)
Und dann Klassennamen wie: File4, List4, Iterator4 - das ist echt
grausam, wieso nicht DB4OFile, DB4OList etc.? Und das ganze auch
noch bei Version 2.7. Scheint mir alles im beta-Stadium zu sein.
Fazit: Ich bleibe bei SQL und meinen eigenen Tools dazu, die tun
auf unterschiedlichen RDBMS (Oracle, MySQL und InstantDB) das, was
sie sollen, speziell im Bereich Database-/ResultSetMetaData.
A.G.
Christian Bauer
>Datenkapselung. Alle Attribute müssen public sein, um per
>Reflection darauf zugreifen zu können. Genau so gut hätte die
>Forderung genügt, alle Attribute müssen öffentliche getter-/setter-
>Methoden haben a la get<AttributeName>()/set<AttributeName>().
Der erste Satz ist so nicht richtig. Bei Hibernate wird jetzt schon seit
laengerem darueber diskutiert, ob typische POJOs eines Domain Models
auch per Instanzvariablen-Zugriff persistent gemacht werden sollen oder
ob JavaBean Properties Vorzug haben. Tatsaechlich wird jetzt nach langer
Diskussion beides unterstuetzt, wie immer public, private und protected,
per Reflection.
>Fazit: Ich bleibe bei SQL und meinen eigenen Tools dazu, die tun
>auf unterschiedlichen RDBMS (Oracle, MySQL und InstantDB) das, was
>sie sollen, speziell im Bereich Database-/ResultSetMetaData.
Das ist allerdings radikal in die andere Richtung. Etwas dazwischen
schon mal probiert?
--
Christian Bauer
Paul Ebermann
> Zusätzlich muß ich sagen, dass mir eure Philosophie in keiner
> Weise zusagt, was die grobe Verletzung eines der wesentlichen
> Grundprinzipien der oo Programmierung verletzt, nämlich die
> Datenkapselung. Alle Attribute müssen public sein, um per
> Reflection darauf zugreifen zu können.
Wie kommst du auf die Idee?
Mit Reflection kann man auch auf private-Attribute
zugreifen, und das macht db4o auch (es sei denn,
in der aktuellen Version ist da ein Bug).
> Alles in allem eine herbe Enttäuschung, die nicht dazu beiträgt,
> objekt-orientierte DB's aus ihrem Nieschendasein zu verhelfen.
> Und dafür in irgendeiner Form Geld zu verlagen, ist so lange
> unseriös, solange ihr offenbar noch nichtmal eure eigenen
> Beispiele auf Herz und Nieren testet. Wo bitte schön kommt z.B.
> das Package javax.print.attribute.standard her?
Bei meinem J2SDK 1.4.0 ist es dabei.
Dass du nur veraltete JDKs nutzt, da kann
Carl ja nichts dafür.
Paul
Frank Radermacher
> "Andree Große" skribis:
>
>>Alles in allem eine herbe Enttäuschung, die nicht dazu beiträgt,
>>objekt-orientierte DB's aus ihrem Nieschendasein zu verhelfen.
>>Und dafür in irgendeiner Form Geld zu verlagen, ist so lange
>>unseriös, solange ihr offenbar noch nichtmal eure eigenen
>>Beispiele auf Herz und Nieren testet. Wo bitte schön kommt z.B.
>>das Package javax.print.attribute.standard her?
>
> Bei meinem J2SDK 1.4.0 ist es dabei.
> Dass du nur veraltete JDKs nutzt, da kann
> Carl ja nichts dafür.
>
Ich hab mir 2.7 noch nicht angeschaut, aber in den Releasenotes steht,
das es jetzt fuer alle jdk's ich glaub ab 1.1 entsprechende jar's, um
obiges zu vermeiden.
Finde ich alles andere als unserioes.
Frank
Paul Ebermann
Naja, es geht um eine Beispiel-Datei.
Die Beispiele müssen nicht notwendigerweise
mit allen JDKs laufen, denke ich.
Paul
Frank Radermacher
> "Frank Radermacher" skribis:
>
> Naja, es geht um eine Beispiel-Datei.
> Die Beispiele müssen nicht notwendigerweise
> mit allen JDKs laufen, denke ich.
>
Das ist genau das was ich meinte. Der von mir dargelegte Sachverhalt des
Vorhandenseins spezieller jar's pro JDK ist ein Zeichen dafuer Probleme
vom Benutzer fernzuhalten und ein Zeichen von Serioesitaet.
AG hielt den db4o download fuer unserioes.
Ich sehe das voellig anders. Carl versucht sich mit einem Businessmodell
das ich so verstanden habe. Kerngesund, weil alles langfristig
finanziell sichergestellt. Saemtliche eingenommenen Mittel werden an der
sinnvollsten Stelle eingesetzt, und da glaube ich das ein holperndes
Demoprogramm auf einem veralteten JDK kein Beinbruch ist. Jeder der
aufgrund von institutionellen Zwaengen alte Technologien einsetzt
besitzt ausreichend Kenntnisse, um problemlos ein Produkt wie db4o zu
testen, sofern man denn wirklich will.
Frank
Carl Rosenberger
Andree Große wrote:
> nachdem du nun so oft db4o hier publiziert hast, dachte ich
> mir, sieh es dir doch mal an und probier es aus. Da ich bisher
> ausschließlich mit SQL-Datenbanken arbeite war mein erster
> Gedanke natürlich der Import vorhandener Datenbankschemas.
[snip]
> Und tschüß...
Lieber Andre,
Dein db4o Testbericht liest sich für mich ungefähr so:
"Als erstes wollten wir bei diesem Porsche Carrera die
Alltagstauglichkeit testen. Der Kinderwagen ging nicht
rein.
...und tschüss.
Dann versuchten wir es mit sieben Bierkästen. Nicht mal
einer ging ins Handschuhfach!
...und tschüss.
Kein Wunder, das Sportwagen nicht öfter auf der Strasse
zu sehen sind."
Jedes Tool hat seinen Anwendungsbereich. db4o ist dafür
gedacht, bestehende *Klassen*schemata (nicht SQL) zu
erkennen und ohne jegliche Administrationsarbeit zu
speichern. Wer schon eine Oracle-Enterprise-Datenbank
hat, auf die er mit viel SQL-Code zugreift, für den ist
db4o nicht gedacht.
db4o ist zum Beispiel ideal für :
- rapid prototyping,
- Auslieferung mit schlanken Applikationen, die auf
möglichst vielen Plattformen laufen sollen,
- den Einsatz bei permormance-kritschen Anwendungen in
der Industrie.
Du magst das Nischen nennen - dort wo es einen echten
Mehrwert im Vergleich zu kostenlosen SQL-Datenbanken gibt,
sind die Anwender auch bereit dafür Geld auszugeben.
Was hast Du davon ausprobiert, um Dein vorschnelles
Urteil zu begründen?
Es wird eine ganz Menge Quellcode als public domain mit
ausgeliefert, der überhaupt nicht zur eigentlichen Engine
(db4o.jar) dazu gehört. Er ist dazu gedacht, daß sich
jeder selbst daraus nach belieben bauen kann, was er
möchte.
Darunter ist auch Code, der aus einer bestehenden
SQL-Datenbank Klassen erstellt. Wenn Du so willst, ist das
in der Tat "Beta" Qualität. Der Code wurde vor ziemlich
genau drei Jahren für erste Tests mit vielen Daten gebaut
und seither überhaupt nicht gepflegt. Das liegt daran, daß
die Funktionalität von Kunden überhaupt nicht nachgefragt
wird.
Die Datei "JClass.jgt" fliegt mit schöner Regelmässigkeit
bei jeder Modifikation des Buildscripts raus. Vielen Dank
für den Hinweis. Anbei die Datei. Dann klappts auch mit
InstantDB und Oracle.
> Zusätzlich muß ich sagen, dass mir eure Philosophie in keiner
> Weise zusagt, was die grobe Verletzung eines der wesentlichen
> Grundprinzipien der oo Programmierung verletzt, nämlich die
> Datenkapselung. Alle Attribute müssen public sein, um per
> Reflection darauf zugreifen zu können.
Das hast Du falsch evaluiert. Ab JDK 1.2 können Felder
(Attribute) sehr wohl auch protected oder public sein.
> Und dafür in irgendeiner Form Geld zu verlagen, ist so lange
> unseriös, solange ihr offenbar noch nichtmal eure eigenen
> Beispiele auf Herz und Nieren testet. Wo bitte schön kommt z.B.
> das Package javax.print.attribute.standard her?
javax.print.attribute.standard ist JDK 1.4., direkt aus rt.jar.
Der Translator ist deswegen als Beispiel mit drin, weil jemand
diese Klasse persistent machen wollte.
Wie gut db4o auf Herz und Nieren getestet ist, kannst Du gerne
selbst ausprobieren. Es wird wesentlich mehr Regressionstest-
Code mit ausgeliefert als eigentliche Datenbankengine. Allein
für S.O.D.A. sinde es über 500 Testfälle.
Du beschwerst Dich, daß wir Geld für db4o verlangen? Mit
Verlaub, ich lebe von db4o. Ich habe eineinhalb Jahre Fulltime
Arbeit vorinvestiert, ohne einen Cent dafür zu verdienen.
Womit verdienst Du Dein Geld? Du verlangst Funktionalität für
Dich, die das macht, was Du Dir vorstellst. Soll ich sie Dir
jetzt sofort kostenlos schreiben? Wer aus freien Stücken seine
Arbeitszeit investiert, ohne etwas dafür zu verlangen, der
ist einfach zu gut für diese Welt.
Übrigens vollzieht sich in der OpenSource-Welt in vielen
Bereichen ein Wandel, bei dem ich mir nicht sicher bin, ob er
insgesamt gut für alle ist. Immer öfter halten die grossen
Megafirmen die Rechte der OpenSource-Projekten und eigentlich
werden die Entwickler ausgebeutet. Beispielsweise steckt
Novell hinter Mono.
Ein anderes Beispiel:
Hibernate hat sich gerade der JBoss Group angeschlossen. Ich
denke, für einen grossen Teil von Hibernate ist Gavin King
verantwortlich. Der hat sicher irrsinnig viel Zeit dafür
investiert. Was hat er jetzt für einen Vorteil davon? Er wird
jetzt immerhin von der JBoss Group für seine *zukünftige* Arbeit
bezahlt.
Hm...
Ich schenke meine Arbeit nicht her.
> Und dann Klassennamen wie: File4, List4, Iterator4 - das ist echt
> grausam, wieso nicht DB4OFile, DB4OList etc.? Und das ganze auch
> noch bei Version 2.7.
Dir ist scheinbar auch klar, daß Namenskonflikte hässlich sind. Ich
finde ein Postfix "4" sehr viel praktischer als ein Prefix "Db4o",
einfach weil die Autoergänzung einem dann von den erten Buchstaben
an hilft. Auch diese Klassen sind wieder public domain Quellcode,
der mit dem eigentlichen Produkt, der db4o.jar, sehr wenig zu tun
hat. Du kannst ihn beliebig mit Eclipse in Minuten refakturieren,
wenn Dir die Benennung nicht gefällt.
> Scheint mir alles im beta-Stadium zu sein.
Du hast über die eigentlich Funktionalität noch überhaupt nichts
geschrieben. Vielleicht hast Du sie gar nicht ausprobiert.
Nein, ich denke über das beta-Stadium sind wir mit dem Kern der
Engine schon seit langem hinaus. Ich finde auch nicht, daß das
Feedback von unseren Benutzern in unserer Newsgroup nach
Beta-Stadium aussieht, was meinst Du?
Andre, was willst Du eigentlich mit Deiner reisserischen Kritik
bezwecken, die hier immer wieder zu lesen ist? Fühlst Du Dich
selbst besser, wenn Du die anderen als dämlich darstellst?
> Fazit: Ich bleibe bei SQL und meinen eigenen Tools dazu, die tun
> auf unterschiedlichen RDBMS (Oracle, MySQL und InstantDB) das, was
> sie sollen, speziell im Bereich Database-/ResultSetMetaData.
Das ist schön für Dich!
Es gibt Anwender, die komplexe tiefe Klassenschemata haben und
deswegen überhaupt nicht mit SQL arbeiten können.
Es gibt auch Anwender, die einfach nur Klassen schreiben wollen
und die für Persistenz keinen Finger krumm machen wollen.
Ich denke, diese "Nische" reicht für Objektdatenbanken voll und
ganz. ....wenn sie denn auch von jedem eingesetzt werden würden,
der davon profitieren würde.
Marco Lange
> Wer sich wundert, warum so wenig Funktionalität so lange gedauert
> hat: Es gibt jetzt eine komplett equivalente C# Version für alle
> ..NET Sprachen, die unter anderem auch auf dem CompactFramework
> (PocketPC, WindowsMobile 2003) läuft. Das heisst aber nicht, daß
> die Java-Version in Zukunft eine geringere Priorität hat.
> Entwickelt wird weiterhin in Java, der C# Code wird mit einem
> eigens dafür gebauten Converter erzeugt.
Läuft db4o eigentlich unter Mono? Wäre mal interessant zu wissen, ob es
dort getestet wurde.
Viele Grüße,
Marco
Marco Lange
Erstmal im Großen und Ganzen ACK für Dein Posting. Aber etwas wollte ich
doch noch hinterfragen:
> Übrigens vollzieht sich in der OpenSource-Welt in vielen
> Bereichen ein Wandel, bei dem ich mir nicht sicher bin, ob er
> insgesamt gut für alle ist. Immer öfter halten die grossen
> Megafirmen die Rechte der OpenSource-Projekten und eigentlich
> werden die Entwickler ausgebeutet. Beispielsweise steckt
> Novell hinter Mono.
Welche Rechte hält Novell denn an Mono? Zitat www.go-mono.com:
"The C# Compiler is released under the terms of the GNU GPL. The runtime
libraries are under the GNU Library GPL. And the class libraries are
released under the terms of the MIT X11 license."
Wenn ich wollte, könnte ich als sofort das Projekt forken und einen
eigenen Mono-Klon verbreiten, wenn ich obige Lizenzen einhalte, die IMHO
nicht zu restriktiv sind.
Viele Grüße,
Marco
Carl Rosenberger
> > Übrigens vollzieht sich in der OpenSource-Welt in vielen
> > Bereichen ein Wandel, bei dem ich mir nicht sicher bin, ob er
> > insgesamt gut für alle ist. Immer öfter halten die grossen
> > Megafirmen die Rechte der OpenSource-Projekten und eigentlich
> > werden die Entwickler ausgebeutet. Beispielsweise steckt
> > Novell hinter Mono.
>
> Welche Rechte hält Novell denn an Mono? Zitat www.go-mono.com:
>
> "The C# Compiler is released under the terms of the GNU GPL. The runtime
> libraries are under the GNU Library GPL. And the class libraries are
> released under the terms of the MIT X11 license."
>
> Wenn ich wollte, könnte ich als sofort das Projekt forken und einen
> eigenen Mono-Klon verbreiten, wenn ich obige Lizenzen einhalte, die IMHO
> nicht zu restriktiv sind.
Ohne Frage, das geht.
Trotzdem sehe ich da zwei Grauzonen:
(1) Ein Teil des Codes wird bezahlt im Auftrag einer Grossfirma
entwickelt und nur *zusätzlich* als GPL freigegeben. Gleichzeitig
behält sich die Firma vor (oder tut das sogar aktiv - z.B. MySQL)
ihre Entwicklung für Geld kommerziell anzubieten. Eigentlich
dürfte in die kommerzielle Version doch kein Code einfließen, der
von Fremden zur GPL-Version beigetragen wird, oder? Das passiert
aber in der Regel trotzdem. Natürlich werden Fixes, die jemand
zur GPL-Version beiträgt, auch in die "eigene" Kern-Version der
Firma übernommen, oder zumindest das Wissen darüber. Damit landet
dann doch Code, der eigentlich unter der GPL produziert wurde, in
einer Version, die für Geld verkauft wird.
(2) Solange es noch in einem frühen Stadium im Bau befindlich ist,
stellt ein so komplexes Projekt wie Mono ohne die Kernentwickler
mit dem zentralen Knowhow keinen großen Wert dar. Du allein
schaffst es eher nicht, das insgesamt weiter zu pflegen. Die
Entwickler stehen aber bei der grossen Firma auf der Gehaltsliste.
Damit hat die Firma sehr viel Macht über den Fortgang des Projekts.
Wenn die Firma beschliesst, nur noch die kommerzielle Version
weiter zu pflegen, kann es passieren, daß das OpenSource-Projekt
auf dem Abstellgeleis stehen bleibt. Ausserdem sind die Entwickler
durch das stabile Gehalt verwöhnt und eine eigenverantwortliche
Gründung einer Marketing- und Support-Abteilung, um diese Gehälter
sicher zu stellen findet nicht statt. Wenn die Firma den Geldhahn
zu dreht, bleibt das Projekt eventuell stehen. Die Entwickler
haben drei Jahre das Gleiche gemacht und Lust auf ein neues Projekt.
Das finanzielle Management ist nicht ihr Geschäft, deswegen können
sie das nicht zusammen stemmen (obwohl es unter Umständen für sie
persönlich hochprofitabel sein könnte. Desto größer und komplexer
ein solches System ist, desto größer ist die Gefahr. Als solche
"tote" OpenSource Projekte aus der Java Welt, die dieses
Schicksal getroffen hat fallen mir spontan ein:
(korrigiert mich bitte, wenn ich mich irre)
- InstantDB
- Castor
- Enhydra
Ich bin nach meinem allerersten Blick auf Mono etwas enttäuscht
aber ich habe für eine fertige Meinung noch zu wenig gesehen.
Ich korrigiere das gerne noch als Antwort auf Dein anderes
Posting (bin gerade beim Mono-Testen).
Viele Grüße,
Carl
Marcus Fihlon
>- Castor
Mensch, kannst Du einen erschrecken! Schwupps nochmal nachgesehen:
Castor is an open source data binding framework for Java[tm]. It's
basically the shortest path between Java objects, XML documents and
SQL tables. Castor provides Java to XML binding, Java to SQL
persistence, and then some more.
News:
September 28, 2003 Version 0.9.5.2 is now available for download.
Gerade gestern kam die neue Version raus -- das macht auf mich einen
durchaus aktiven Eindruck.
cu
Marcus
--
"Dann schreib das doch bzw. verhalte Dich so. Wie man in die Newsgroup
hineinkräht, so ei-duziduzidu-t es wieder raus."
Dirk Nimmich (de.comp.datenbanken.mysql)
Marco Lange
> (1) Ein Teil des Codes wird bezahlt im Auftrag einer Grossfirma
> entwickelt und nur *zusätzlich* als GPL freigegeben. Gleichzeitig
> behält sich die Firma vor (oder tut das sogar aktiv - z.B. MySQL)
> ihre Entwicklung für Geld kommerziell anzubieten. Eigentlich
> dürfte in die kommerzielle Version doch kein Code einfließen, der
> von Fremden zur GPL-Version beigetragen wird, oder? Das passiert
> aber in der Regel trotzdem. Natürlich werden Fixes, die jemand
> zur GPL-Version beiträgt, auch in die "eigene" Kern-Version der
> Firma übernommen, oder zumindest das Wissen darüber. Damit landet
> dann doch Code, der eigentlich unter der GPL produziert wurde, in
> einer Version, die für Geld verkauft wird.
Das ist richtig. Ich weiß aber ehrlich gesagt nicht, ob dies nicht
trotzdem mit der GPL konform geht, solange sichergestellt ist, dass jede
Änderung die in das kommerzielle Produkt von außen einfließt auch in das
GPL-Produkt einfließt. Wenn ich eine Veränderung am MySQL-Code vornehme
und die übernommen wird in die GPL-Version, und damit unter GPL weiter
veröffentlicht wird, sind damit die Lizenzbedingungen erfüllt, auch wenn
MySQL den gleichen Code in der kommerziellen Variante verwendet. So sehe
ich das, aber ich bin auch alles andere als ein Jurist.
> (2) Solange es noch in einem frühen Stadium im Bau befindlich ist,
> stellt ein so komplexes Projekt wie Mono ohne die Kernentwickler
> mit dem zentralen Knowhow keinen großen Wert dar. Du allein
> schaffst es eher nicht, das insgesamt weiter zu pflegen. Die
> Entwickler stehen aber bei der grossen Firma auf der Gehaltsliste.
> Damit hat die Firma sehr viel Macht über den Fortgang des Projekts.
> Wenn die Firma beschliesst, nur noch die kommerzielle Version
> weiter zu pflegen, kann es passieren, daß das OpenSource-Projekt
> auf dem Abstellgeleis stehen bleibt. Ausserdem sind die Entwickler
> durch das stabile Gehalt verwöhnt und eine eigenverantwortliche
> Gründung einer Marketing- und Support-Abteilung, um diese Gehälter
> sicher zu stellen findet nicht statt. Wenn die Firma den Geldhahn
> zu dreht, bleibt das Projekt eventuell stehen. Die Entwickler
> haben drei Jahre das Gleiche gemacht und Lust auf ein neues Projekt.
> Das finanzielle Management ist nicht ihr Geschäft, deswegen können
> sie das nicht zusammen stemmen (obwohl es unter Umständen für sie
> persönlich hochprofitabel sein könnte. Desto größer und komplexer
> ein solches System ist, desto größer ist die Gefahr. Als solche
> "tote" OpenSource Projekte aus der Java Welt, die dieses
> Schicksal getroffen hat fallen mir spontan ein:
> (korrigiert mich bitte, wenn ich mich irre)
> - InstantDB
> - Castor
> - Enhydra
Du hast natürlich recht, ich alleine würde es nicht hinbekommen, das
Projekt weiter zu pflegen. Auch eine völlig neue Entwicklermannschaft
bräuchte erstmal viel Zeit, um sich den Code anzusehen. Wenn aber
Interesse besteht, und vor allem kommerzielles Interesse, so wird evtl.
die nächste Firma kommen, investieren und das Projekt weiter entwickeln.
Wenn kein kommerzielles Interesse besteht, stirbt das Projekt.
Auch Open Source Projekt können ab eine bestimmten Größe nicht mehr frei
von kommerziellen Aspekten operieren, fast alle mir bekannten wirklich
großen OS-Projekte stehen zumindest teilweise unter Kontrolle von Firmen
(nach Deiner Def. von Kontroll, soll heißen, die Entwickler sind bei
irgendwelchen Firmen angestellt): Mozilla, Open Office, Linux, Eclipse
Teilweise können das verschiedene Firmen sein, aber in jedem Fall steht
kommerzielles Interesse dahinter.
Ein Vorteil der OS-Szene ist zu gleich ihr größter Nachteil: Die
Dynamik. Genauso schnell wie neue Projekte aus dem Boden gestampft
werden, verlieren evtl. die Entwickler auch wieder die Lust an der
Entwicklung, und das Projekt verfällt in den Stillstand. Andererseits
gibt es aber auch seit Jahren aktive Projekte, die einen großen Einfluss
auf die Computerbranche haben, z.B. das Apache-Projekt oder eben die
Entwicklung des Linux-Kernels und das GNU-Projekt.
Ich verstehe hingegen aber nicht, warum Du über diese Entwicklung, dass
viele OS-Projekte von Firmen koordiniert werden, besorgt bist.
Sicherlich besteht immer die Gefahr, dass die Firma irgendwann aus
kommerziellen Interessen das Projekt einstellt, aber das kann doch bei
einem Closed-Source-Projekt genauso passieren, nur mit dem Unterschied,
dass dann niemand mehr etwas davon hat. Bei OS kann wenigstens noch
etwas mit dem Code angefangen werden, wenn sich jemand dazu aufrafft.
Ich sehe dort also keine besorgniserregenden Nachteile, ich halte Open
Source für unglaublich wichtig für die Weiterentwicklung der
Softwarebranche ansich. Immer sinkt mit zunehmender Anzahl der zur
Verfügung stehenden Open-Source-LOC die Wahrscheinlichkeit, dass ich das
Rad wieder mal neu erfinden muss, wenn ich etwas entwickle.
Viele Grüße,
Marco
Carl Rosenberger
Marcus Fihlon wrote:
> >- Castor
>
> Gerade gestern kam die neue Version raus -- das macht auf mich einen
> durchaus aktiven Eindruck.
Sorry, dann war meine Information falsch.
Ich hatte vor gut über einem Jahr was in der OJB
Mailingliste mitgelesen. Sinngemäß so:
"Exolab steckt da nichts mehr rein, also bezahlen wir
jetzt Entwickler [X] (russischer Name) selbst, damit
überhaupt ein wenig vorwärts geht."
...na gut, "tot" ist dann auch was anderes.
Du weisst das scheinbar viel besser. Ich lese schon eine
ganze Weile nicht mehr in den einschlägigen Mailinglisten
mit und sollte wohl lieber meinen Mund halten.
Viele Grüße,
Carl
Carl Rosenberger
> Ich verstehe hingegen aber nicht, warum Du über diese Entwicklung, dass
> viele OS-Projekte von Firmen koordiniert werden, besorgt bist.
Ich sehe eine immer stärkere Zentralisierung und damit
immer weniger die Chance, daß sich eine junge kleine
Firma mit einem eigenen Projekt durch setzen kann.
Ausserdem ist es für mich Ausbeutung, wenn eine große
Firma mit einem kommerziellen Produkt daran verdient,
daß viele Entwickler kostenlos dazu beitragen.
Schließlich fürchte ich für die Zukunft Patentstreitigkeiten,
bei denen nur die Großen gewinnen können.
Die Großen werden immer größer und stärker. Für die Kleinen
bleibt kein Raum, um unabhängig zu starten.
Angenommen es gibt ein Team X, mit fünf sehr guten Entwicklern,
die zielstrebig an einem guten Produkt arbeiten. Meiner Ansicht
nach ist es für die Softwarebranche insgesamt besser, wenn sie
das unabhängig tun und in vertretbarem Masse Geld dafür
verlangen, als wenn sie für eine große Firma arbeiten und ihr
Code OpenSource ist.
Naja, so pauschal lässt sich das wirklich nicht sagen.
Eclipse ist ganz ganz große Klasse.
Den Sun-JCP finde ich ziemlich mies.
Viele Grüße,
Carl
Frank Radermacher
> Marco Lange wrote:
>
>>Ich verstehe hingegen aber nicht, warum Du über diese Entwicklung, dass
>>viele OS-Projekte von Firmen koordiniert werden, besorgt bist.
>
> Ich sehe eine immer stärkere Zentralisierung und damit
> immer weniger die Chance, daß sich eine junge kleine
> Firma mit einem eigenen Projekt durch setzen kann.
Das ist nicht ausschliesslich ein Problem der IT. Es sind die gleichen
Mechanismen eigentlich ueberall festzustellen, ohne jetzt gleich auf
Globalisierung schimpfen zuwollen. Es geht um die Ausschaltung des
freien Marktes und der Konkurenz.
> Ausserdem ist es für mich Ausbeutung, wenn eine große
> Firma mit einem kommerziellen Produkt daran verdient,
> daß viele Entwickler kostenlos dazu beitragen.
Ja
> Schließlich fürchte ich für die Zukunft Patentstreitigkeiten,
> bei denen nur die Großen gewinnen können.
Ja
> Die Großen werden immer größer und stärker. Für die Kleinen
> bleibt kein Raum, um unabhängig zu starten.
Ja. Es handelt sich um "vorsaetzliche Eingrenzung von proffessionellem
Lebensraum" ;-)
> Angenommen es gibt ein Team X, mit fünf sehr guten Entwicklern,
> die zielstrebig an einem guten Produkt arbeiten. Meiner Ansicht
> nach ist es für die Softwarebranche insgesamt besser, wenn sie
> das unabhängig tun und in vertretbarem Masse Geld dafür
> verlangen, als wenn sie für eine große Firma arbeiten und ihr
> Code OpenSource ist.
Solange es Vollblutunternehmer gibt ja. Aber ich kann mir ohne weiteres
ein Opensourceproject vorstellen wo viele kleine Firmen was Heisses auf
die Beine stellen, ohne die eigene Existenz ueber das erstellte Produkt
definieren zu muessen.
An genau dieser Stelle sehe ich die Zukunft fuer OpenSource.
Das geschieht heute schon bei Eclipse, ich denke aber auch an nicht IT
Firmen.
> Naja, so pauschal lässt sich das wirklich nicht sagen.
Es ist Marktpolitik Carl. Die Monopole sind heute so fett, das sie
bestimmen wer in America President wird. Vergleiche mal Haushaltszahlen
mit den Bilanzsummen der Grossen.
Was Dich so aufbringt, ist das Du Dich in Deinen
Entfaltungsmoeglichkeiten begrenzt siehst bzw. bist. Und da bin ich mit
Dir voellig einer Meinung. Das ist sehr schlecht.
> Eclipse ist ganz ganz große Klasse.
> Den Sun-JCP finde ich ziemlich mies.
>
> Viele Grüße,
> Carl
Frank
P.S. Versetz Dich in die Lage eines Bauern der auf seinem Hof als
"Dienstleistung" das Vieh des Futtermittelfaelschers maestet. Da bleibt
auch keine Initiative mehr uebrig.
Ich habe aber trozdem noch Hoffnung, das wir hier in Europa um das
Schlimmste drumherum kommen koennten - vielleicht. So ein tolles System
wie das kuerzlich angesprochene der Polizei hilft da bestimmt.
Paul Ebermann
> > (1) Ein Teil des Codes wird bezahlt im Auftrag einer Grossfirma
> > entwickelt und nur *zusätzlich* als GPL freigegeben. Gleichzeitig
> > behält sich die Firma vor (oder tut das sogar aktiv - z.B. MySQL)
> > ihre Entwicklung für Geld kommerziell anzubieten. Eigentlich
> > dürfte in die kommerzielle Version doch kein Code einfließen, der
> > von Fremden zur GPL-Version beigetragen wird, oder?
Ja. Wobei hier die Frage ist, was "von Fremden zur GPL-Version
beigetragen" bedeutet ...
> > Das passiert
> > aber in der Regel trotzdem. Natürlich werden Fixes, die jemand
> > zur GPL-Version beiträgt, auch in die "eigene" Kern-Version der
> > Firma übernommen, oder zumindest das Wissen darüber. Damit landet
> > dann doch Code, der eigentlich unter der GPL produziert wurde, in
> > einer Version, die für Geld verkauft wird.
>
> Das ist richtig. Ich weiß aber ehrlich gesagt nicht, ob dies nicht
> trotzdem mit der GPL konform geht, solange sichergestellt ist, dass jede
> Änderung die in das kommerzielle Produkt von außen einfließt auch in das
> GPL-Produkt einfließt.
Nein.
> Wenn ich eine Veränderung am MySQL-Code vornehme
> und die übernommen wird in die GPL-Version, und damit unter GPL weiter
> veröffentlicht wird, sind damit die Lizenzbedingungen erfüllt, auch wenn
> MySQL den gleichen Code in der kommerziellen Variante verwendet. So sehe
> ich das, aber ich bin auch alles andere als ein Jurist.
Natürlich kann jedermann (also auch MySQL) den GPL-Code
außenstehender Entwickler intern beliebig nutzen.
Was sie laut GPL nicht dürfen, ist: ihn (bzw. ein daraus
resultierendes Programm) unter einer nicht-GPL weiterzugeben.
Und das ist doch die "kommerzielle MySQL-Variante", oder?
Aber ich nehme an, dass es dafür eine extra-Klausel gibt,
wo jeder Mensch, der etwas beiträgt (bzw. abschickt),
zustimmt, dass er sein Copyright an die Firma abtritt.
(Ähnlich bei den GNU-Projekten: Da tritt auch
jeder Entwickler sein Copyright an die FSF ab.)
Paul
Uwe Matthaeus
>
>Schließlich fürchte ich für die Zukunft Patentstreitigkeiten,
>bei denen nur die Großen gewinnen können.
>
Das ist genau das, was mir auch Sorgen macht. :-(
Diese jetzige schwammige Regelung schafft keine Rechtssicherheit. Die Kopplung
'Hardware <-> Software --> Patent moeglich' ist doch ein Witz. Ich nehme ein
einfaches Stueck Hardware einen guten(!) Patentanwalt und schon schalte ich
mit der 'zugehoerigen' Software missliebige Konkurenz aus. Ein guter Anwalt ver-
mittelt den Doedeln im Patentamt schon das die Software nur Nebensache zur
Hardware ist. Was in Bezug auf Patente moeglich ist, sehe ich jeden Tag in
der Firma.
MfG
Uwe
Frank Radermacher
> Natürlich kann jedermann (also auch MySQL) den GPL-Code
> außenstehender Entwickler intern beliebig nutzen.
>
> Was sie laut GPL nicht dürfen, ist: ihn (bzw. ein daraus
> resultierendes Programm) unter einer nicht-GPL weiterzugeben.
> Und das ist doch die "kommerzielle MySQL-Variante", oder?
>
> Aber ich nehme an, dass es dafür eine extra-Klausel gibt,
> wo jeder Mensch, der etwas beiträgt (bzw. abschickt),
> zustimmt, dass er sein Copyright an die Firma abtritt.
Und das gleiche steht auch irgendwo bei db4o. Das ganze ist auch an
vielen Stellen durchaus ok und zwar dann, wenn nicht schon von Anfang an
ein Ungleichgewicht zwischen den Seiten vorliegt. Wenn das vorliegt geht
es um Ausbeutung.
Noch problematischer und Bauchschmerz verursachend faende ich eine
Situation in der ein talentierter Mathematiker (Paul) einem befreundeten
sehr positiven und engagiertem man weiss nicht genau ob Unternehmer,
Coder, Realist oder was weiss ich dclj Kollegen ;-) eine tolle Idee in
Code umsetzt und zur Verfuegung stellt, und im Laufe der Jahre das
ultimative dbWunder entsteht mit dem entsprechenden Euroregen ...
bis dahin alles ok. Wenn jetzt aber die Umsetzung dieser Idee patentiert
wird, und niemand damit weitermachen kann?
Das gleiche gilt fuer die von Carl angesprochene Situation, in der
defacto niemand ein Project weiterfuehren kann. Das ist dann wirklich
Ausbeutung, weil es halt Leute gibt die umsonst arbeiten, und andere die
kassieren. Das gab es schon immer und heisst Ausbeutung.
Was man dagegen tun kann laesst sich auch an der Geschichte ablesen. Der
erste Punkt ist Aufmerksamkeit zu erregen. Wenn man die Protokolle der
EP-Sitzungen liest sieht man sofort welchen Effekt die Mobilisation quer
durch die Parteien hatte. Das unerzogene Gebloeke von XUL- und anderen
Technologiegeistern ist in dem Sinne voellig kontraproduktiv. Es fuehrt
genau auf die Ebene, auf der die Grossen die besseren Karten haben.
Es ist ein sehr komplexes Gebiet. Was man getrost sagen kann, ist das
man sich regelmaesig damit beschaeftigen sollte, angefangen in der
Schule. Sieht man die Bedeutung dieser Sachverhalte verstehe ich nicht
das in der Schule nicht darauf eingegangen wird.
Frank
Andree Große
> "Andree Große" skribis:
>
>>Reflection darauf zugreifen zu können.
>
> Wie kommst du auf die Idee?
So steht's in der db4o-Doku...
A.G.
Andree Große
> Ich hab mir 2.7 noch nicht angeschaut, aber in den Releasenotes steht,
> das es jetzt fuer alle jdk's ich glaub ab 1.1 entsprechende jar's, um
> obiges zu vermeiden.
Sehr witzig - was glaubst du welches jar ich probiert habe?
Ich sag's dir: das aus dem Folder jdk1.3. Noch Fragen?
A.G.
Andree Große
> Paul Ebermann wrote:
>
>> "Frank Radermacher" skribis:
>>
>> Naja, es geht um eine Beispiel-Datei.
>> Die Beispiele müssen nicht notwendigerweise
>> mit allen JDKs laufen, denke ich.
>>
>
> Das ist genau das was ich meinte. Der von mir dargelegte Sachverhalt des
> Vorhandenseins spezieller jar's pro JDK ist ein Zeichen dafuer Probleme
> vom Benutzer fernzuhalten und ein Zeichen von Serioesitaet.
>
> AG hielt den db4o download fuer unserioes.
Du kannst noch nichtmal lesen. Ich hielt und halte es
für unseriös, für bestimmte Dinge öffentlich zu werben
(was ja prinzipiell das gute Recht von Carl ist) und
dann Geld für die Teilnahme am Forum etc. zu verlangen.
(100$ privat und 1000$ für eine Firma pro Jahr) Wenn
offenbar noch nichtmal die Dinge funktionieren, die in
der mitgelieferten Doku beschrieben sind. Oder glaubst
du es war innere Eingebung, dass ich SQLImport probiert
habe? Nur verträgt der Verfasser offenbar keine Kritik,
im übrigen ist es rein sachlich, wenn ich darauf hinweise,
dass der typische Fehler gemacht wird, Statement-Objekte
nicht unmittelbar nach Benutzung wieder zu schließen.
Die zitierte Fehlermeldung vom Oracle-Thin-Treiber war
lediglich eine fachlich absolut korrekte Ergänzung, um
auf den Mangel aufmerksam zu machen. Vor gut 5 Jahren
bin ich selbst beim Wechsel zwischen Sybase und Oracle
mal damit auf die Nase gefallen. Wenn sich db4o für solche
Hinweise nicht interessiert, ist das in meinen Augen entweder
maßlose Arroganz (was ich jedoch nicht wirklich unterstellen
will) oder aber einfach nur Gleichgültigkeit gegenüber
Nutzern, die bisher RDBMS und SQL genutzt haben und nun
gern mal einen anderen Weg probieren wollten.
Eines der beschriebenen Feature (und das entnahm ich
der Doku zu db4o) ist JDBC-Fähigkeit und SQL-Import/Export.
Dieser funktioniert nicht und das habe ich auch ganz
konkret beschrieben. Die Methoden der DatabaseMetaData
werden nicht korrekt benutzt. Diese Kritik scheint aber
offenbar nicht erwünscht zu sein. Wenn ich öffentlich
publiziere, dann muß ich mich auch öffentlicher Kritik
stellen. Doch zu konkreten Mängeln nimmt Carl offenbar
nicht so gerne Stellung. Wenn Schwächen im Bereich
JDBC auf RDBMS bestehen, dann sollten diese zukünftig
behoben werden - oder dieses Feature einfach weglassen.
Weiter im Text: Wenn es schon unterschiedliche jar-Dateien
für die JDK's gibt, wie kann dann beim Versuch, Klassen
generieren zu wollen, vorausgesetzt werden, dass das
Package javax.print.attribute.standard aus JDK 1.4 verfügbar ist?
Das paßt nicht zusammen. Daraus ergibt sich, dass auch diese
Funktionalität für JDK's < 1.4 gar nicht verfügbar ist.
Vielleicht solltest du mein Posting nochmal lesen, es
war nämlich ganz konkret. Das Auslesen aus einem RDBMS
geht schief, das Generieren von Klassen geht schief.
Und ich halte es schlicht für Selbstgefälligkeit nachdem
Probleme mit angepriesenen Features auftreten zu sagen:
Na das ist ja eigentlich auch alles gar nicht dafür
gedacht gewesen.
A.G.
btw: es gibt gute Gründe, warum sich oo DB's nicht
durchgesetzt haben.
Michael Wein
> btw: es gibt gute Gründe, warum sich oo DB's nicht
> durchgesetzt haben.
Die da wären? Offenkundig hast du ja große Erfahrung in dem Bereich.
In diesem Zusammenhang "empfehle" ich auch das Online-Forum von heise, wo
auf die Meldung hin, dass Poet und Versant fusionieren, die Experten sich
zu Wort melden.
--
Michael Wein
Carl Rosenberger
> >>.... Alle Attribute müssen public sein, um per
> >>Reflection darauf zugreifen zu können.
> >
> > Wie kommst du auf die Idee?
>
> So steht's in der db4o-Doku...
Dann hast Du möglicherweise den Satz davor überlesen. Wörtlich:
Limitations if you run your applications on JDK 1.1.x:
(this also includes PersonalJava, EPOC)
- A class needs to have at least one public constructor.
- Fields have to be declared public, to allow values to be accessed by reflection.
Andree Große
> Die da wären? Offenkundig hast du ja große Erfahrung in dem Bereich.
Sie fristen im kommerziellen Bereich ein Nischen-Dasein.
Das zeigt der Markt selbst - Fürsprecher hin oder her.
Auch das Gerede von Objekt-Relationalen DB's wird immer leiser.
A.G.
Andree Große
>
> Andree Große wrote:
>
>>nachdem du nun so oft db4o hier publiziert hast, dachte ich
>>mir, sieh es dir doch mal an und probier es aus. Da ich bisher
>>ausschließlich mit SQL-Datenbanken arbeite war mein erster
>>Gedanke natürlich der Import vorhandener Datenbankschemas.
>
> [snip]
Geschickt, wie du konkrete Fehlermeldungen und berechtigte
konkrete Kritik nach /dev/null umleitest, statt darauf einzugehen.
Laßt das Feature SQLImport/Export einfach weg, wenn ihr Probleme
mit JDBC habt. Meine angeführte Korrektur z.B. bei getTables()
war sogar hilfreich angedacht, aber das willst du ja offenbar
nicht sehen. zitat:
> Richtig sollte es lauten: meta.getTables(null, schema, "%", types);
> Bei Oracle entspricht das z.B. dem User-Name.
> Lieber Andre,
Ich wäre dir verbunden, wenn du meinen Namen richtig schreiben
könntest, um Verwechslungen zu vermeiden. Wie man gut sehen
kann, werde ich am Ende mit Doppel-e geschrieben. Ich schreibe
ja auch nicht Karl.
> Dein db4o Testbericht liest sich für mich ungefähr so:
>
> "Als erstes wollten wir bei diesem Porsche Carrera die
> Alltagstauglichkeit testen. Der Kinderwagen ging nicht
> rein.
> ...und tschüss.
> Dann versuchten wir es mit sieben Bierkästen. Nicht mal
> einer ging ins Handschuhfach!
> ...und tschüss.
> Kein Wunder, das Sportwagen nicht öfter auf der Strasse
> zu sehen sind."
Wenn man so wie du die wesentlichen und vor allem konkreten
Teile wegläßt, dann liest es sich vielleicht so. Aber ich
zitiere mal aus der Doku zu db4o (aus jdbc.html):
SqlImport
com.db4o.sql.SqlImport imports data from a data source that is unknown to the
db4o system.
Parameters:
<JDBC driver> <JDBC connection String> <destination db4o data file> <package>
For every table a .Java file will be created in the package folder specified as
parameter.
The .Java files will be automatically compiled if javac is found on your system.
For every row in the database, an object will be created within db4o.
JDBC Drivers
Our experiences with JDataConnect from NetDirect were excellent.
Databases
The migration mechanism should work on any database, providing metadata
information is available over the JDBC interface.
The current implementation has been tested with a Sybase database and with
Microsoft Access.
Sybase offers a free version of Adaptive Server Enterprise for Linux.
Was jetzt - war es so angedacht oder nicht?
> Jedes Tool hat seinen Anwendungsbereich. db4o ist dafür
> gedacht, bestehende *Klassen*schemata (nicht SQL) zu
> erkennen und ohne jegliche Administrationsarbeit zu
> speichern.
Die Einschränkung 'nicht SQL' widerspricht eurer eigenen Doku
(siehe oben). Aber es traten Probleme auf (wie z.B. falsches
Benutzen der DatabaseMetaData-Methoden als auch unglückliches
Handling von Statement-Objekten) und von denen willst du offenbar
nichts hören.
> Wer schon eine Oracle-Enterprise-Datenbank
> hat, auf die er mit viel SQL-Code zugreift, für den ist
> db4o nicht gedacht.
Wie dumm von mir, es dennoch ausprobiert zu haben.
(Ich habe eure Doku nicht geschrieben.) Eigentlich hatte
ich die Möglichkeit des SQLImports als Anreiz betrachtet,
mir db4o endlich mal genauer anzusehen. Und wenn dabei
die ersten Erfolge schnell sichtbar würden, wäre es ja
für bestimmte Fälle eine mögliche Alternative. Nun gut
wer nicht will, der hat schon.
> ...
> Du magst das Nischen nennen - dort wo es einen echten
> Mehrwert im Vergleich zu kostenlosen SQL-Datenbanken gibt,
Dieser Mehrwert liegt worin?
> sind die Anwender auch bereit dafür Geld auszugeben.
Dazu sollte man bei jeder guten Software bereit sein, weil
diese nämlich Produkt geistiger Arbeit ist. Aber gerade in dieser
NG werden die Tools dafür stets kostenlos verlangt. Wieviel
bist du bereit für Eclipse auszugeben? (rein rhetorische Frage)
> Was hast Du davon ausprobiert, um Dein vorschnelles
> Urteil zu begründen?
Das hab ich doch beschrieben - Oder? Als ersten Schritt
die Migration vorhandener Daten auf ein anderes System,
wie es in der Praxis nunmal üblich ist. Dort stößt man
nämlich stets auf vorhandene Infrastrukturen. und das
erlebe ich seit über 12 Jahren Anwendungsentwicklung.
> Es wird eine ganz Menge Quellcode als public domain mit
> ausgeliefert, der überhaupt nicht zur eigentlichen Engine
> (db4o.jar) dazu gehört. Er ist dazu gedacht, daß sich
> jeder selbst daraus nach belieben bauen kann, was er
> möchte.
Mit hart-codierten Template-Namen in Java-Klassen, wobei
man den Aufbau eines solchen Templates noch nichtmal kennt?
> Die Datei "JClass.jgt" fliegt mit schöner Regelmässigkeit
> bei jeder Modifikation des Buildscripts raus. Vielen Dank
> für den Hinweis. Anbei die Datei. Dann klappts auch mit
> InstantDB und Oracle.
Das DBMS ist doch dabei völlig egal. Das wäre mir auch bei
Access und Sybase passiert, nachdem das Schema ausgelesen
wurde und die Klassen generiert werden sollen.
> Das hast Du falsch evaluiert. Ab JDK 1.2 können Felder
> (Attribute) sehr wohl auch protected oder public sein.
Und was ist mit private? (Datenkapselung auf tiefster Ebene)
> javax.print.attribute.standard ist JDK 1.4., direkt aus rt.jar.
> Der Translator ist deswegen als Beispiel mit drin, weil jemand
> diese Klasse persistent machen wollte.
Einen solchen Hinweis kann ich in der Doku nicht finden.
Ich habe natürlich auch das richtige jar aus dem JDK1.3-Folder
verwendet.
> Du beschwerst Dich, daß wir Geld für db4o verlangen?
Hier hättest du mal das Zitat stehen lassen sollen. Ich beschwere
mich deswegen darüber, weil angepriesene Features gar nicht
funktionieren und nicht generell.
> Ich schenke meine Arbeit nicht her.
Das hat niemand verlangt.
> Dir ist scheinbar auch klar, daß Namenskonflikte hässlich sind. Ich
> finde ein Postfix "4" sehr viel praktischer als ein Prefix "Db4o",
> einfach weil die Autoergänzung einem dann von den erten Buchstaben
> an hilft.
Klar doch Liste4, Datum3, Person12 sind Klassennamen, die ziemlich
deutlich sagen, was sie abbilden. Jetzt wird's echt lächerlich.
> Auch diese Klassen sind wieder public domain Quellcode,
> der mit dem eigentlichen Produkt, der db4o.jar, sehr wenig zu tun
> hat.
Kein Grund nicht durchgängig schlüssig und intuitiv vorzugehen.
Es gibt da bei der Benamsung seit Jahren ein paar Empfehlungen.
Und diese sind übrigens von der konkreten Sprache völlig unabhängig.
Ausgangspunkt für technische Implementierungen sind Fachklassen-Modelle.
Aber ich merke schon, du hast deine eigene Welt und die ist offenbar
restriktiv.
> Du kannst ihn beliebig mit Eclipse in Minuten refakturieren,
> wenn Dir die Benennung nicht gefällt.
Aha - was wenn ich gar kein Eclipse verwende?
> Andre, was willst Du eigentlich mit Deiner reisserischen Kritik
> bezwecken, die hier immer wieder zu lesen ist? Fühlst Du Dich
> selbst besser, wenn Du die anderen als dämlich darstellst?
Ich habe ganz konkret Fehler beschrieben und sogar Lösungen
angeboten (nochmal siehe oben). Polemisch reagierst du darauf.
A.G.
Michael Wein
Durch Weglassen deiner ursprünglichen Aussage verdrehst du hier Ursache und
Wirkung. Du hattest ursprünglich gesagt:
[Andree Große in blbcis$c7q$1...@ppd00021.deutschepost.de]
> es gibt gute Gründe, warum sich oo DB's nicht durchgesetzt haben
Hierauf meine Bitte, diese Gründe denn dann auch zu nennen.
Ich warte immer noch.
--
Michael Wein
Carl Rosenberger
> Ich habe ganz konkret Fehler beschrieben und sogar Lösungen
> angeboten (nochmal siehe oben). Polemisch reagierst du darauf.
Andree, (Entschuldige, "Karl" mit "K" war keine Absicht.)
bitte probier es doch einfach nochmal mit der Datei JClass.jgt, die
ich an das andere Posting angehängt habe.
Deine persönliche Lösung für den Zugriff auf die Metadaten hast Du
ja schon gefunden.
Alledings ist der Import Lauf nicht ganz ohne:
Er generiert Java Quellcode Dateien und die werden während des
Imports kompiliert. Der Code dazu ist in
com.db4o.jgen.JClass#compile():
String cmd = "javac -classpath " + classPath + " " + l_File.getAbsolutePath();
Runtime.getRuntime().exec(cmd).waitFor();
Derjenige, der das geschrieben hat, (Ich vor drei Jahren.) wußte wohl
nicht, daß man auf den Compiler sehr viel besser auch direkt zugreifen
kann, wenn man die tools.jar einbindet:
new com.sun.tools.javac.v8.JavaCompiler().compile()
In der Tat könnte man mit einem Tag Arbeit den alten Code dramatisch
verbessern.
Immerhin gibt es die Möglichkeit, den generierten Code von Hand zu
kompilieren und danach den Import mit SQLImportContinue fort zu setzen.
Ganz herzlichen Dank für die Fehlermeldungen zum Import und danke für
den Hinweis, das Statements geschlossen werden müssen. Auch die
JClass.jgt gehört natürlich mit in die Destribution.
Ich habe deswegen polemisch reagiert, weil Du unser Produkt als ganzes
schlecht gemacht hast und es als BETA-Version bezeichnet hast. Damit tust
Du uns sehr unrecht, denke ich.
Ich würde mich freuen, wenn Du dem Import eine zweite Chance geben würdest.
Erwarte Dir aber davon bitte keine Wunder. Wie gesagt, das ist Uralt-Code
von vor drei Jahren (inklusive der Dokumentation), völlig ungepflegt weil
die Funktionalität entweder überhaupt nicht nachgefragt wird oder die
Leute sich das selbst beheben.
Private Felder können übrigens mit allen Versionen ab JDK 1.2 auch
gespeichert werden.
Wenn Dich der JDK 1.4 Beispielscode beim Kompilieren mit Deinem alten
1.3er JDK stört, kannst Du ihn gefahrlos löschen:
SET DB4O_HOME=C:\db4o2.7\
del %DB4O_HOME%src\com\db4o\samples\bind\BindColors.java
del %DB4O_HOME%src\com\db4o\samples\bind\BindColors1.java
del %DB4O_HOME%src\com\db4o\samples\constants\ConstantColors.java
del %DB4O_HOME%src\com\db4o\samples\translators\TDateTimeAtCreation.java
...beziehungsweise wohl schneller von Hand, bei nur 4 Dateien.
Ich würde mich über weiteres qualifiziertes Feedback von Dir freuen.
Marco Lange
> Ich sehe eine immer stärkere Zentralisierung und damit
> immer weniger die Chance, daß sich eine junge kleine
> Firma mit einem eigenen Projekt durch setzen kann.
Ok, das ist aber ein Phänomen, das mit Open Source erstmal überhaupt
nichts zu tun hat, sondern auch (oder gerade) in der Closed-Source-Welt
sehr verbreitet ist, ja sogar noch weit darüber hinaus in mehr oder
weniger jedem kommerziellen oder industriellen Sektor, den ich kenne.
Diese Entwicklung ist in der Tat besorgniserregend, ob es nun in der
Automobilindustrie ist, oder in der Softwareindustrie.
> Ausserdem ist es für mich Ausbeutung, wenn eine große
> Firma mit einem kommerziellen Produkt daran verdient,
> daß viele Entwickler kostenlos dazu beitragen.
Wenn die Entwickler dies freiwillig tun, dann ist es für mich keine
Ausbeutung. Wenn ich Dir jeden Monat freiwillig 1000 Euro schenke, dann
ist es keine Ausbeutung, wohl aber, wenn Du mich dazu zwingst, dies zu
tun. Wenn ich an MySQL mitarbeite, dann weiß ich, dass da eine Firma
dahintersteht mit entsprechenden Interessen, und dass es da auch eine
kommerzielle Variante gibt. Wahrscheinlich gibt es, wie von Paul
angemerkt, eine Art Einverständniserklärung. Wenn ich mich darauf
einlasse, ist alles in Butter.
> Schließlich fürchte ich für die Zukunft Patentstreitigkeiten,
> bei denen nur die Großen gewinnen können.
>
> Die Großen werden immer größer und stärker. Für die Kleinen
> bleibt kein Raum, um unabhängig zu starten.
Ack.
> Angenommen es gibt ein Team X, mit fünf sehr guten Entwicklern,
> die zielstrebig an einem guten Produkt arbeiten. Meiner Ansicht
> nach ist es für die Softwarebranche insgesamt besser, wenn sie
> das unabhängig tun und in vertretbarem Masse Geld dafür
> verlangen, als wenn sie für eine große Firma arbeiten und ihr
> Code OpenSource ist.
Ja, aber wenn es eine kleine Firma ist mit Open Source, dann ist es
sogat noch besser. Ich finde nicht, dass Open Source in irgendeiner Art
und Weise Innovationen hemmt oder behindert, eher im Gegenteil.
Natürlich muss diese Firma ein Geschäftsmodell finden, das mit OS
verträglich ist. Tut sie das nicht, sollte sie bei Closed Source bleiben
und niemand (zmd. ich nicht) hat etwas dagegen.
> Naja, so pauschal lässt sich das wirklich nicht sagen.
>
> Eclipse ist ganz ganz große Klasse.
> Den Sun-JCP finde ich ziemlich mies.
Ack.
Viele Grüße,
Marco
Andree Große
> [Andree Große in blbcis$c7q$1...@ppd00021.deutschepost.de]
>
>>es gibt gute Gründe, warum sich oo DB's nicht durchgesetzt haben
>
> Hierauf meine Bitte, diese Gründe denn dann auch zu nennen.
Sie unterstützen nicht das, was "da draußen" wirklich gebraucht
wird. Vor allem unter dem Aspekt, dass es idR schon eine Infra-
struktur oft mit RDBMS gibt und nicht jedes Unternehmen einfach
mal so eben umsteigt z.B. ohne sichere Migrationskonzepte für
vorhandene Datenbestände wenn ein echter Mehrwert dabei nicht
erkannt werden kann. Zumal auch meist noch weitere Clients auf
die Systeme zugreifen und der Customizing-Aufwand teilweise extrem
groß werden würde. Auch andere Vorteile eines RDBMS (und dieses
hat nunmal nicht nur Nachteile) werden von oo DB's nicht unterstützt,
wie z.B. referentielle Integritäten auf der DB und weitere Constraints,
nebst Stored Pocedures, Triggern etc. Und ich habe seit 12 Jahren
mit unterschiedlichen RDBMS zu tun gehabt, nur mit einem ODBMS
_noch_ nicht. Das wollte ich ja jetzt mal in Angriff nehmen,
aber naja.
Irgendwie hinterlassen diese den Eindruck, daß _technische_ Objekte
sich so technisch einfacher speichern lassen und das ganze bei oftmals
erheblicher Datenredundanz. Und das wollen eben die meisten nicht.
Richtig überzeugt haben oo DB's den Markt eben nicht, sonst würden
diese ja wohl eine gehörige Rolle spielen. Vielleicht lag es ja auch
an solchen Standpunkten wie von Carl bzgl. solcher Aussagen a la:
na für Import von Daten aus SQL-DB's war's ja auch nicht gemacht.
A.G.
Wanja Gayk
> >>es gibt gute Gründe, warum sich oo DB's nicht durchgesetzt haben
> >
> > Hierauf meine Bitte, diese Gründe denn dann auch zu nennen.
>
> Sie unterstützen nicht das, was "da draußen" wirklich gebraucht
> wird.
Was wäre denn das?
Gruss,
-Wanja-
--
At a funeral, the Real Programmer is the one saying "Poor George. And he
almost had the sort routine working before the coronary."
[http://www.pbm.com/~lindahl/real.programmers.html]
Bernd 'Nexos' Dutkowski
RTFL, der war gut. Aber man steht da leider auf verlorenem Posten. Das
geht nur auf die harte Tour, und selbst da verliert man, wenn der Kunde
das Schmerzensgeld aufbringt. Boese Welt.
bernd
Paul Ebermann
> Ich würde mich freuen, wenn Du dem Import eine zweite Chance geben würdest.
> Erwarte Dir aber davon bitte keine Wunder. Wie gesagt, das ist Uralt-Code
> von vor drei Jahren (inklusive der Dokumentation), völlig ungepflegt weil
> die Funktionalität entweder überhaupt nicht nachgefragt wird oder die
> Leute sich das selbst beheben.
Vielleicht sollte das in der Dokumentation
klarer so formuliert werden.
Paul
Marco Lange
> Du kannst noch nichtmal lesen.
*plonk*
Dein Verhalten hier zeigt mir, dass Du nicht die nötige soziale
Kompetenz aufweist, um hier sinnvolle Beiträge zu leisten. Du kannst
nicht richtig argumentieren und wirst ausfallend und beleidigend, wenn
Dir die Argumente ausgehen. Das muss ich mir nicht mehr antun.
Marco
Frank Radermacher
Oder vielleicht sogar ein Dreiteiler
1. official package
2. goodies
3. baddies ;-)
Frank
P.S. Je mehr desto gut?
Carl Rosenberger
> Läuft db4o eigentlich unter Mono? Wäre mal interessant zu wissen, ob es
> dort getestet wurde.
Die gleiche Frage kam auch von Freshmeat zurück, als ich db4o.NET
als neuen Branch dort gepostet habe. :-)
Nach ersten Tests mit Mono 0.26:
(Anweisungen beziehen sich auf das Projekt db4o2.7net.sln im db4o
Download für .NET, also im Regressionstest. Die einzelnen Tests
kann man in com.db4o.test.AllTests#Main an- und abschalten.)
- FileStream.Lock() wird von Mono noch nicht unterstützt. Das kann
man in db4o in ../src/net/Compat#lockFileStream() abschalten, indem
man die Zeile
fs.Lock(0, 1);
einfach auskommentiert.
- WeakReferences scheinen noch nicht zu laufen. Die kann man aus
schalten, indem man in ../src/core/Platform#hasWeakReferences()
false zurück gibt.
- mono (die Runtime) hat irgendwo ein Problem mit DateTime Werten.
Nachdem das in mint (der Interpreter) nicht auftritt, ist das
Problem sicher nicht mehr von langer Dauer. Ich beschränke meine
Tests also nur noch auf mint.
Mit obigen Modifikationen laufen fehlerfrei durch:
- com.db4o.BenchMark.cs
- com.db4o.test.Regression.cs
- soda.test.SodaTest.cs
Die neueren Regressionstests in com.db4o.AllTests stolpern zum
Teil noch ein wenig, sehen aber gar nicht so schlecht aus.
Vielleicht muß da noch zusätzlich ein dedizierter Build für Mono her.
Gefühlsmäßig habe ich den Eindruck, daß sie Threading noch nicht so
ganz im Griff haben. Issjaauchwirklichnicheinfach.
Nachdem Mono für mich nach dem ersten blinden Test (Crash Hoch 3) auf
den ersten Blick so aussah, als ob noch gar nichts geht, ziehe ich
jetzt mein negatives Urteil zurück. Das dauert nicht mehr lange,
dann kan man das auch für komplexere Applikationen sinnvoll
einsetzen. Wär schön!
Frank Radermacher
> Frank Radermacher wrote:
>
>> Paul Ebermann wrote:
>>
>>> "Frank Radermacher" skribis:
>>>
>>> Naja, es geht um eine Beispiel-Datei.
>>> Die Beispiele müssen nicht notwendigerweise
>>> mit allen JDKs laufen, denke ich.
>>>
>>
>> Das ist genau das was ich meinte. Der von mir dargelegte Sachverhalt
>> des Vorhandenseins spezieller jar's pro JDK ist ein Zeichen dafuer
>> Probleme vom Benutzer fernzuhalten und ein Zeichen von Serioesitaet.
>>
>> AG hielt den db4o download fuer unserioes.
>
>
> Du kannst noch nichtmal lesen.
Du hast voellig recht Andree. Und es waere sicherlich besser fuer mich
und insbesondere fuer meine Mitmenschen dieser unertraeglichen
Belaestigung durch grenzenlose Inkompetenz ein Ende zu setzen.
Meintest Du das?
> Ich hielt und halte es
> für unseriös, für bestimmte Dinge öffentlich zu werben
> (was ja prinzipiell das gute Recht von Carl ist) und
> dann Geld für die Teilnahme am Forum etc. zu verlangen.
> (100$ privat und 1000$ für eine Firma pro Jahr) Wenn
> offenbar noch nichtmal die Dinge funktionieren, die in
> der mitgelieferten Doku beschrieben sind. Oder glaubst
> du es war innere Eingebung, dass ich SQLImport probiert
> habe?
Ich finde es trotz der von Dir geschilderten Probleme ein durch und
durch "serioeses" Geschaeftsmodell, sauber umgesetzt, und entspricht
genau dem was ich mir wuensche.
> Nur verträgt der Verfasser offenbar keine Kritik,
Da Du hier mitliest weisst Du es besser.
> im übrigen ist es rein sachlich,
Nein, nein, nein.
Es war Vieles, ich wuerde sagen sogar fast Alles sachlich.
Bei weitem war es aber nicht "rein" sachlich.
Und genau auf diese fehlende "reine" Sachlichkeit sind hier IMHO alle,
Carl inbegriffen reingefallen.
> wenn ich darauf hinweise,
> dass der typische Fehler gemacht wird, Statement-Objekte
> nicht unmittelbar nach Benutzung wieder zu schließen.
> Die zitierte Fehlermeldung vom Oracle-Thin-Treiber war
> lediglich eine fachlich absolut korrekte Ergänzung, um
> auf den Mangel aufmerksam zu machen. Vor gut 5 Jahren
> bin ich selbst beim Wechsel zwischen Sybase und Oracle
> mal damit auf die Nase gefallen. Wenn sich db4o für solche
> Hinweise nicht interessiert, ist das in meinen Augen entweder
> maßlose Arroganz
Das freut mich jetzt wirklich sehr. Ich gehe davon aus das wir damit
wirklich ein Stueck weiterkommen. Ich entnehme Deiner obigen Aeusserung
Arroganz ist negativ.
Das faende ich wirklich toll wenn wir uns hier darauf einigen, dass
Verhaltensweisen die hier allgemeinhin als arrogant angesehen werden
abgestellt werden.
> (was ich jedoch nicht wirklich unterstellen
> will) oder aber einfach nur Gleichgültigkeit gegenüber
> Nutzern, die bisher RDBMS und SQL genutzt haben und nun
> gern mal einen anderen Weg probieren wollten.
>
> Eines der beschriebenen Feature (und das entnahm ich
> der Doku zu db4o) ist JDBC-Fähigkeit und SQL-Import/Export.
> Dieser funktioniert nicht und das habe ich auch ganz
> konkret beschrieben. Die Methoden der DatabaseMetaData
> werden nicht korrekt benutzt. Diese Kritik scheint aber
> offenbar nicht erwünscht zu sein. Wenn ich öffentlich
> publiziere, dann muß ich mich auch öffentlicher Kritik
> stellen. Doch zu konkreten Mängeln nimmt Carl offenbar
> nicht so gerne Stellung. Wenn Schwächen im Bereich
> JDBC auf RDBMS bestehen, dann sollten diese zukünftig
> behoben werden -
ja
> oder dieses Feature einfach weglassen.
nein
> Weiter im Text: Wenn es schon unterschiedliche jar-Dateien
> für die JDK's gibt, wie kann dann beim Versuch, Klassen
> generieren zu wollen, vorausgesetzt werden, dass das
> Package javax.print.attribute.standard aus JDK 1.4 verfügbar ist?
ja
> Das paßt nicht zusammen. Daraus ergibt sich, dass auch diese
> Funktionalität für JDK's < 1.4 gar nicht verfügbar ist.
>
> Vielleicht solltest du mein Posting nochmal lesen, es
> war nämlich ganz konkret. Das Auslesen aus einem RDBMS
> geht schief, das Generieren von Klassen geht schief.
> Und ich halte es schlicht für Selbstgefälligkeit nachdem
> Probleme mit angepriesenen Features auftreten zu sagen:
> Na das ist ja eigentlich auch alles gar nicht dafür
> gedacht gewesen.
>
> A.G.
> btw: es gibt gute Gründe, warum sich oo DB's nicht
> durchgesetzt haben.
Wuerde ich gerne mehr von Dir zu hoehren. Insbesondere konkrete
Forderungen im Sinne von "wenn Du ooDB-Mensch das und das implementierst
ist es fuer mich sinnvoll einsetzbar."
Stefan Matthias Aust
> - FileStream.Lock() wird von Mono noch nicht unterstützt.
> - WeakReferences scheinen noch nicht zu laufen.
Laut http://www.go-mono.com/class-status-corlib.html ist Lock
tatsächlich noch TODO aber WeakReferences sollte vorhanden sein. Das das
nicht funktioniert solltest du vielleicht hier
http://www.go-mono.com/bugs.html melden.
bye
--
Stefan Matthias Aust // "Ist es normal, nur weil alle es tun?" -F4
Thomas Bensler
>>Zusätzlich muß ich sagen, dass mir eure Philosophie in keiner
>>Weise zusagt, was die grobe Verletzung eines der wesentlichen
>>Grundprinzipien der oo Programmierung verletzt, nämlich die
>>Datenkapselung. Alle Attribute müssen public sein, um per
>>Reflection darauf zugreifen zu können.
>
> Das hast Du falsch evaluiert. Ab JDK 1.2 können Felder
> (Attribute) sehr wohl auch protected oder public sein.
Nur mal so aus Interesse: warum nicht auch private (evtl. unter dem
Vorbehalt, dass es der SecurityManager erlaubt)?
TIA, Thomas.
Frank Radermacher
> Hi!
>
>> Du kannst noch nichtmal lesen.
>
> *plonk*
>
> Dein Verhalten hier zeigt mir, dass Du nicht die nötige soziale
> Kompetenz aufweist,
Fehlende Kompetenz stoert IMHO die Kompetenten immer oder meistens. Es
ist dann auch nicht leicht damit kompetent umzugehen.
Nach meiner Meinung ist ein sinnvoller Weg, den Inkompetenten
aufzufordern Kompetenz aufzubauen. Genau da tut der meiner Meinung nach
sehr IT kompetente Andree regelmaessig einen abgrundtiefen Graben zu
seiner "sozialen" Kompetenz auf. Anstatt zu helfen Kompetenz aufzubauen
wird lediglich ein Schuldgefuehl dafuer geliefert inkompetent zu sein.
Die von AG verursachte Schimpfe ihm gegenueber ist da inhaltlich nicht
viel anders.
> um hier sinnvolle Beiträge zu leisten.
Ich hoffe ich habe nichts uebersehen, aber wie folgt.
Carl hat das neue db4o 2.7 angekuendigt, mit der Bitte um
Stellungnahmen, um anhand dieser Stellungnahmen Ideen fuer
Produktverbesserungen zu erhalten.
Der einzige Punkt der bereits zu Produktverbesserungen bei db4o gefuehrt
hat war der von Andree. Insofern kann ich Dir nicht beipflichten im
Sinne von sinnvoll. Im Sinne des OP ist es der einzig sinnvolle Beitrag
bis jetzt.
> Du kannst
> nicht richtig argumentieren und wirst ausfallend und beleidigend, wenn
> Dir die Argumente ausgehen.
Die Argumentation ist insgesamt glaube ich gar nicht so loecherig, es
ist die Form die stoert.
> Das muss ich mir nicht mehr antun.
Faende ich schade. Ich bin jetzt seit ungefaehr 6 Monaten hier auf dclj
unterwegs, und es bringt mir jedenfalls sehr viel hier teilzunehmen. Im
Vergleich zu anderen NG's herrscht hier eine generell sehr angenehme
Umgangsform.
An dem letzten Post vom XUL-Geist war INHO auch nichts mehr auszusetzen.
Frank
Marco Schmidt
>> Das hast Du falsch evaluiert. Ab JDK 1.2 können Felder
>> (Attribute) sehr wohl auch protected oder public sein.
>
>Nur mal so aus Interesse: warum nicht auch private (evtl. unter dem
>Vorbehalt, dass es der SecurityManager erlaubt)?
War vermutlich nur Verdreher (Carl schrieb "oder public", meinte aber
"oder private"). Ansonsten ergibt es keinen Sinn als Antwort auf die
Kritik "Alle Attribute müssen public sein".
Gruß,
Marco
--
Bitte nur in der Newsgroup antworten, nicht per Email!
de.comp.lang.java Homepage: http://www.dclj.de/
FAQ: http://www.faqs.org/faqs/de/comp-lang-java/faq/
Meine Java-Seiten: http://www.geocities.com/marcoschmidt.geo/java.html
Marco Lange
> Fehlende Kompetenz stoert IMHO die Kompetenten immer oder meistens. Es
> ist dann auch nicht leicht damit kompetent umzugehen.
>
> Nach meiner Meinung ist ein sinnvoller Weg, den Inkompetenten
> aufzufordern Kompetenz aufzubauen. Genau da tut der meiner Meinung nach
> sehr IT kompetente Andree regelmaessig einen abgrundtiefen Graben zu
> seiner "sozialen" Kompetenz auf. Anstatt zu helfen Kompetenz aufzubauen
> wird lediglich ein Schuldgefuehl dafuer geliefert inkompetent zu sein.
Damit hast Du natürlich recht, es mag vielleicht etwas überreagiert
sein, dass ich Andree geplonkt habe, aber auch jetzt, einen Tag später,
werde ich es nicht mehr rückgängig machen, weil ich mich wahrscheinlich
heute abend schon wieder über eines seiner Postings aufregen würde. Ich
bin normalerweise sehr geduldig, und ich habe mir monatelang hier seine
Postings durchgelesen und es hat mich oft geärgert, aber was solls.
Genauso habe ich mir ein Zeit lang die Postings von Gerald Bauer
angetan, aber irgendwnan ist einfach schluss.
Ich finde ehrlich gesagt auch nicht, dass ich dafür verantwortlich bin,
bei ihm soziale Kompetenz zu erzeugen. Wenn ich mich danebenbenehme im,
werde ich auch bestenfalls gemieden, je nachdem an wen ich gerate,
könnte ich auch cshon mal eins aufs Dach bekommen. Aber wenn ich
jemandnen durch mein Verhalten belästige oder störe, ist es doch nicht
an dem jenigen gelegen mich zu ändern. Wenn er mich dann meidet und wir
uns aus dem Weg gehen, ist doch die Sache für ihn erledigt, wenn ich
mich danach immer noch nicht ändern, dann ist das allein meine Sache.
Um wieder auf Andree zurückzukommen, er ist schon häufig genug hier
darauf hingewiesen wurde, sich etwas zusammenzureißen. Ich will ihn
durch mein Plonken nicht bestrafen sondern ihm einfach, wie oben
beschrieben, aus dem Weg gehen. Spätetens, wenn ich mal mein System
neuinstallieren, wenn ich einen neuen Rechner habe, oder meinen
NEwsreader wechsele, ist das Plonk quasi aufgehoben, da ich soclhe
Sachen im allgemeinen nicht übernehme. Hat er sich (oder der XUL-Geist)
dann geändert, wunderbar, ansonsten eben nicht.
Ein Plonk ist für mich in erster linie eine Aussage über mich selbst,
nicht über ihn. Ich kann mir ja auch kein persönliches Urteil über ihn
erlauben, da ich ihn nur in Form seiner NG-Postings kenne, und diese
stören mich eben. Und dem verleihe ich eben ausdruck.
> Die von AG verursachte Schimpfe ihm gegenueber ist da inhaltlich nicht
> viel anders.
Richtig, ich sehe hier nur ein anderes Ursache-Wirkungs-Prinzip.
Sicherlich ist es richtig, dass Andree in IT-Dingen sehr kompentent ist,
und es ist auch nicht spezielle dieses Posting, war mich stört, sondern
seine Postings im allgemeinen. Mich hat auch die Antwort auf Carls
Ursprungsposting nicht gestört, aber allein der Ausspruch
"Du kannst noch nicht einmal lesen"
stößt mir sehr übel auf. Wenn er gesagt hätte, "du kannst nicht lesen,
ich hab das und das geschrieben", dann hätte ich das als zynischen
Kommentar abgetan, aber allein die beiden Wörtchen "noch nichtmal" finde
ich sehr herabwertend Dir gegenüber. Du zählst hier ja schon zu den
kompententen (zum Glück sowohl in fachlicher als auch in sozialer
Hinsicht, IMHO) Regulars.
> Carl hat das neue db4o 2.7 angekuendigt, mit der Bitte um
> Stellungnahmen, um anhand dieser Stellungnahmen Ideen fuer
> Produktverbesserungen zu erhalten.
>
> Der einzige Punkt der bereits zu Produktverbesserungen bei db4o gefuehrt
> hat war der von Andree. Insofern kann ich Dir nicht beipflichten im
> Sinne von sinnvoll. Im Sinne des OP ist es der einzig sinnvolle Beitrag
> bis jetzt.
Wie gesagt, ich bezog mich auf Andrees Antwort auf Dein Posting.
>> Du kannst nicht richtig argumentieren und wirst ausfallend und
>> beleidigend, wenn Dir die Argumente ausgehen.
>
> Die Argumentation ist insgesamt glaube ich gar nicht so loecherig, es
> ist die Form die stoert.
Ack. Fachliche Kompetenz kann man Andree nicht absprechen.
>> Das muss ich mir nicht mehr antun.
> Faende ich schade. Ich bin jetzt seit ungefaehr 6 Monaten hier auf dclj
> unterwegs, und es bringt mir jedenfalls sehr viel hier teilzunehmen. Im
> Vergleich zu anderen NG's herrscht hier eine generell sehr angenehme
> Umgangsform.
Ich meinte auch nicht, dass ich nicht mehr an der Newsgroup teilnehmen
will, sondern an Andrees Postings. Ich lerne hier auch viel, und
versuche, anderen zu helfen, mir gefällt das allgemeine Klima sehr gut
hier, eben bis auf ein paar Ausnahmen.
Viele Grüße
Marco
Carl Rosenberger
> > Das hast Du falsch evaluiert. Ab JDK 1.2 können Felder
> > (Attribute) sehr wohl auch protected oder public sein.
>
> Nur mal so aus Interesse: warum nicht auch private (evtl. unter dem
> Vorbehalt, dass es der SecurityManager erlaubt)?
Äh, ja, natürlich auch private.
Das wollte ich eigentlich oben schreiben. Ich probiere es nochmal:
"Das hast Du falsch evaluiert. Ab JDK 1.2 können Felder (Attribute)
sehr wohl auch protected oder private deklariert sein, sie werden
in jedem Fall gespeichert."
Andree Große
> ...
> Ich würde mich freuen, wenn Du dem Import eine zweite Chance geben würdest.
> Erwarte Dir aber davon bitte keine Wunder. Wie gesagt, das ist Uralt-Code
> von vor drei Jahren (inklusive der Dokumentation), völlig ungepflegt weil
> die Funktionalität entweder überhaupt nicht nachgefragt wird oder die
> Leute sich das selbst beheben.
Würde ich wirklich gern nochmal angehen, nur was mache
ich mit einer Datei:
Könntest du mir das Template JClass.jgt bitte direkt an meine
Email-Adresse senden? Ich werde mir auch die Dateien im sql-Package
alle ansehen, weil mir weiter aufgefallen ist, dass weder Statements
noch ResultSet's je geschlossen werden. Sobald ich damit fertig bin,
diesbezüglich Anpassungen vorzunehmen und meine Erfahrungen im
Bereich JDBC auf RDBMS einzubringen, werde ich dir die geänderten
Dateien in diesem Package per Email schicken.
A.G.
Frank Radermacher
es ist hier ein wenig untergegangen, aber es wuerde mich wirklich
interessieren, wo Du rDBMS einem ooDBMS als ueberlegen ansiehst.
Bzw. warum der Markt so gering ist.
Frank
Steffen Ramlow
> es ist hier ein wenig untergegangen, aber es wuerde mich wirklich
> interessieren, wo Du rDBMS einem ooDBMS als ueberlegen ansiehst.
Also ich sage mal:
* kann sehr große Datenmengen verwalten
* skaliert sehr gut
* Einbindung anderer Datenquellen
* Standard-Schnittstelle (SQL)
* sehr ausgereift
Andree Große
> Hi Andree,
>
> es ist hier ein wenig untergegangen, aber es wuerde mich wirklich
> interessieren, wo Du rDBMS einem ooDBMS als ueberlegen ansiehst.
Und wieder wird falsch zitiert! Und dann wundert ihr euch, wenn
man euch vorwirft, dass einige hier nicht richtig lesen können.
Zitat:
> btw: es gibt gute Gründe, warum sich oo DB's nicht
> durchgesetzt haben.
>
Wo steht hier was von irgendeiner Überlegenheit?
Oder hab ich was am Auge?
> Bzw. warum der Markt so gering ist.
Ist er es etwa nicht? Das beantwortet der Markt doch selber.
Ich kann mir lediglich einige Gründe dafür vorstellen und
das habe ich hier: news://blc0tr$6av$1...@ppd00021.deutschepost.de
auch getan.
A.G.
Und warum hat man denn die Debatte um Objekt-Relationale DBMS begonnen?
Dafür muß es ja wohl Gründe geben - Oder?
Andree Große
> Richtig, ich sehe hier nur ein anderes Ursache-Wirkungs-Prinzip.
Oder meinst du hier den allein geltenden eigenen Maßstab?
Du findest also sowas wie PLONK, KILL, >/dev/null etc.
sozial kompetenter? Nun man lernt nie aus.
> .... Mich hat auch die Antwort auf Carls
> Ursprungsposting nicht gestört, aber allein der Ausspruch
>
> "Du kannst noch nicht einmal lesen"
>
> stößt mir sehr übel auf. Wenn er gesagt hätte, "du kannst nicht lesen,
> ich hab das und das geschrieben", dann hätte ich das als zynischen
> Kommentar abgetan,
Nun gut, dann mal das vollständige Zitat: (dort steht genau das
was du nicht sehen willst bzw. einforderst)
>>
>> AG hielt den db4o download fuer unserioes.
>
> Du kannst noch nichtmal lesen. Ich hielt und halte es
> für unseriös, für bestimmte Dinge öffentlich zu werben
> ...
Ich hielt eben _nicht_ den Download für unseriös.
Das nenne ich Inhalte verfälscht wiedergeben.
Kompetenzen hin oder her, Fachwissen hin oder her - aber eines
kann ich partout nicht ausstehen: wenn falsch zitiert wird!
(Geht übrigens mit Copy&Paste am besten... ;-)
Denn dann werden Inhalte verändert und es geht nicht mehr um
fachlichen Inhalt sondern um persönliche Vorlieben. Und niemand
verlangt, dass wir uns lieben müssen.
A.G.
Frank Radermacher
> Frank Radermacher wrote:
>
>> Hi Andree,
>>
>> es ist hier ein wenig untergegangen, aber es wuerde mich wirklich
>> interessieren, wo Du rDBMS einem ooDBMS als ueberlegen ansiehst.
>
>
> Und wieder wird falsch zitiert!
Wo liest Du hier ein Zitat? Mich interessiert Deine Meinung zum Thema.
Fertig.
Sehr wohl habe ich Dir jedoch unterstellt, dass Du rDBMS einem ooDBMS
gegenueber als ueberlegen ansiehst. Wenn ich damit falsch liege habe ich
was nicht richtig verstanden, aber 90% der Leser unterstellen Dir das
aufgrund Deiner Aeusserungen wohl auch.
Genau deswegen hat mich einfach interessiert, wo der Grund lag dann doch
eine ooDBMS zu testen.
Destomehr ich den Eindruck hatte, das es sich bei Deinem Test nicht um
rein akademisches Interesse handelt, sondern um eine konkrete
Evaluierung der Anwendbarkeit in Deinem Umfeld.
Und genau da ist meine Frage anzusiedeln. Ich haette sowas naehmlich
nicht erwartet.
> Und dann wundert ihr euch, wenn
> man euch vorwirft, dass einige hier nicht richtig lesen können.
Du kannst mir vorwerfen was Du willst, ich finde es halt schade. In
einer "ehrlichen" Diskussion geht es IMHO darum nach "treu und glauben"
zu versuchen die gegenseitigen Positionen herauszuarbeiten, und
herauszufinden ob und wenn wo Unterschiede bestehen.
In diesem Sinne kann sogar ein falsches Zitat eine Diskussion erheblich
weiterbringen, weil es naehmlich deutlich macht, wo der andere falsch
interpretiert hat. Sollte ich irgendwo falsch zitieren so liegt es
tatsaechlich daran dass ich nicht lesen kann.
Treffen wuerde mich vielmehr ein Vorwurf, wissentlich die Position eines
anderen anders darzustellen als ich um sie weiss.
> Zitat:
>
> > btw: es gibt gute Gründe, warum sich oo DB's nicht
> > durchgesetzt haben.
Und genau daher mein Interesse.
> Wo steht hier was von irgendeiner Überlegenheit?
> Oder hab ich was am Auge?
implizit schon.
>> Bzw. warum der Markt so gering ist.
>
> Ist er es etwa nicht? Das beantwortet der Markt doch selber.
> Ich kann mir lediglich einige Gründe dafür vorstellen und
> das habe ich hier: news://blc0tr$6av$1...@ppd00021.deutschepost.de
> auch getan.
Ich komm an den post nicht ran.
> A.G.
> Und warum hat man denn die Debatte um Objekt-Relationale DBMS begonnen?
> Dafür muß es ja wohl Gründe geben - Oder?
Frank
Andree Große
> Andree Große wrote:
>
>> Frank Radermacher wrote:
>>
>>> Hi Andree,
>>>
>>> es ist hier ein wenig untergegangen, aber es wuerde mich wirklich
>>> interessieren, wo Du rDBMS einem ooDBMS als ueberlegen ansiehst.
>>
>> Und wieder wird falsch zitiert!
>
> Wo liest Du hier ein Zitat? Mich interessiert Deine Meinung zum Thema.
> Fertig.
>
> Sehr wohl habe ich Dir jedoch unterstellt, dass Du rDBMS einem ooDBMS
> gegenueber als ueberlegen ansiehst. Wenn ich damit falsch liege habe ich
> was nicht richtig verstanden, aber 90% der Leser unterstellen Dir das
> aufgrund Deiner Aeusserungen wohl auch.
Zum letzten Mal. Ich habe festgestellt, dass es Gründe gibt, warum sich
ODBMS nicht durchgesetzt haben. Damit ziehe ich znächst keinerlei Vergleich
bzgl. Überlegenheit von A gegenüber B oder umgekehrt. Es ist eine Feststellung
und keine Wertung. Die Interpretation einer solchen, ist rein subjektiv
bedingt und nur weil du hier (etwas anmaßend) glaubst für 90% der anderen
zu sprechen, heißt das noch lange nicht, dass ich das behauptet hätte.
(man sollte stets nur für sich selber sprechen)
Ich sage was ich denke und tue was ich sage. Und nicht das, was du glaubst,
das ich gemeint haben könnte. (Ende des Knotens)
> Du kannst mir vorwerfen was Du willst, ich finde es halt schade. In
> einer "ehrlichen" Diskussion geht es IMHO darum nach "treu und glauben"
> zu versuchen die gegenseitigen Positionen herauszuarbeiten, und
> herauszufinden ob und wenn wo Unterschiede bestehen.
ACK - aber Unterstellungen gehören dann nicht dazu. Eine Formulierung
der Form: 'willst du damit sagen, dass RDBMS den ODBMS in allen Punkten
überlegen sind' ließe den Verdacht einer Unterstellung gar nicht erst
aufkommen. Ist der Unterschied jetzt deutlich geworden?
Übrigens würde ich die Frage zumindest in Punkto 'in allen Punkten'
nicht unbedingt mit ja beantworten.
> In diesem Sinne kann sogar ein falsches Zitat eine Diskussion erheblich
> weiterbringen, weil es naehmlich deutlich macht, wo der andere falsch ...
M.E. birgt ein falsches Zitat nichts Positives in sich, ganz im Gegenteil,
wie man deutlich sehen kann.
>> Wo steht hier was von irgendeiner Überlegenheit?
>> Oder hab ich was am Auge?
>
> implizit schon.
Wie du ganz richtig vermutest, sehe ich das nicht so.
Das war es dann zu diesen Punkten.
A.G.
Carl Rosenberger
[Marktakzeptanz von Objektdatenbanken (ODBMS)]
> Vielleicht lag es ja auch
> an solchen Standpunkten wie von Carl bzgl. solcher Aussagen a la:
> na für Import von Daten aus SQL-DB's war's ja auch nicht gemacht.
Jetzt zitierst Du mich aber falsch.
Der Code ist sehr wohl für den Import gemacht (wofür sonst?), er wird
aber meines Wissens von Kunden kaum eingesetzt.
Unsere typischen Kunden schreiben neue Applikationen in Java/C# und
freuen sich darüber, daß sie für Datenbankfunktionalität so gut wie
keine zusätzliche Arbeit investieren müssen.
Enterprise-Anwendungen, in denen viele unterschiedliche Applikationen
gleichzeitig über SQL auf eine Datenbank zugreifen sind ganz klar nicht
unser Zielmarkt. Da gibt es zu viel Konkurrenz. Meines Wissens nach
funktioniert in diesem Bereich keine Objektdatenbank besonders gut.
Die Vorteile von Objektdatenbanken kommen besonders zum Tragen:
- wenn man tiefe Klassenhierarchien oder sehr vielen Klassen hat,
- für rapid prototyping / rapid application development, wenn
man nur das Klassenschema pflegen will und sonst nichts
- wenn man hohe Anforderungen an die Objekt-Speicher- und Objekt-
Instantiierungs-Geschwindigkeit stellt,
- wenn man den Ressourcenverbrauch minimieren will,
- wenn man Applikationen oft refakturiert und sich dabei den Aufwand
sparen will, String-Bindungen, Tabellen- und Mapping-Dateien zu
warten.
Für andere Anwendungsgebiete gibt es prinzipiell kein technisches
Hindernis, daß Objektdatenbanken schlechter funktionieren als
herkömliche relationale Datenbanken. Sie sind aber trotzdem in
manchen Bereichen unterlegen, weil der Entwicklungsschwerpunkt klar
auf einer engen Objekt-/Sprachenverzahnung liegt und keine einzige
der Firmen genügend Geld in die Entwicklung der relationalen
Features steckt.
Von den noch (O2 ist kaputt) lebendigen Produkten sind POET und
Versant bei SQL-Fähigkeiten klar am weitesten [1].
Interessanterweise haben sich genau diese beiden Firmen gerade
zusammen geschlossen. Für Restrukturierungskosten und für zukünftig
175 Mitarbeiter ist das restliche Kapitalpolster von USD 8m sehr
dünn, fürchte ich, vor allem angesichts der Zahlen die POET und
Versant in den letzten Jahren geschrieben haben. Für mich ist die
dabei entstehende Firma ein Übernahmekandidat.
[1] sieht man von den Code-Generatoren Intersystems Caché und Matisse
ab, die dafür wesentlich schlechter mit bereits bestehenden Klassen
klar kommen.
Carl Rosenberger
> > Ich würde mich freuen, wenn Du dem Import eine zweite Chance geben würdest.
>
> ich mit einer Datei:
>
Nanu, gibt es noch Newsreader, die keine Dateianhänge lesen können? :-)
> Könntest du mir das Template JClass.jgt bitte direkt an meine
> Email-Adresse senden?
Done.
> Ich werde mir auch die Dateien im sql-Package alle ansehen, weil mir
> weiter aufgefallen ist, dass weder Statements noch ResultSet's je
> geschlossen werden. Sobald ich damit fertig bin, diesbezüglich
> Anpassungen vorzunehmen und meine Erfahrungen im Bereich JDBC auf
> RDBMS einzubringen, werde ich dir die geänderten Dateien in diesem
> Package per Email schicken.
Das wäre ausgesprochen nett, vielen Dank.
Markus Fritsche
> Interessanterweise haben sich genau diese beiden Firmen gerade
> zusammen geschlossen. Für Restrukturierungskosten und für zukünftig
> 175 Mitarbeiter ist das restliche Kapitalpolster von USD 8m sehr
> dünn, fürchte ich, vor allem angesichts der Zahlen die POET und
> Versant in den letzten Jahren geschrieben haben. Für mich ist die
> dabei entstehende Firma ein Übernahmekandidat.
Aber du willst dir den Stress doch nicht wirklich antun?
MfG Markus
Paul Ebermann
ROTFL.
Paul
Michael Wein
> * kann sehr große Datenmengen verwalten
> * skaliert sehr gut
> * Einbindung anderer Datenquellen
> * Standard-Schnittstelle (SQL)
> * sehr ausgereift
Bis auf den Fehler mit SQL beschreibst du die Vorzüge von ODBMS sehr gut.
--
Michael Wein
Gerd Nachtsheim
Hmmm, hast Du jetzt nicht einen Smiley vergessen? Die Bedeutungslosigkeit von
reinen OODBMS kommt nicht ganz von ungefähr.
Gerd
--
Gerd Nachtsheim mailto:ge...@users.sourceforge.net ICQ:#13126958
Michael Wein
> Michael Wein wrote:
>
> > On Thu, 2 Oct 2003 11:27:17 +0200, Steffen Ramlow wrote:
> >
> > >* kann sehr große Datenmengen verwalten
> > >* skaliert sehr gut
> > >* Einbindung anderer Datenquellen
> > >* Standard-Schnittstelle (SQL)
> > >* sehr ausgereift
> >
> > Bis auf den Fehler mit SQL beschreibst du die Vorzüge von ODBMS sehr gut.
>
> Hmmm, hast Du jetzt nicht einen Smiley vergessen? Die Bedeutungslosigkeit von
> reinen OODBMS kommt nicht ganz von ungefähr.
Nein, habe ich nicht. Welcher der Punkte denkst du denn, treffen auf ODBMS
nicht zu? Und bitte Erfahrungswerte, kein "ich hab mal gehört".
--
Michael Wein
Frank Radermacher
Wenn ich's dann mal einfach umdrehen darf heisst das, dass Du
Erfahrungswerte hast beim
- handling grosser Datenmengen
- ecc.
Mich interessieren "Reinfaelle" viel weniger als "Erfolge" beim Einsatz
reiner ooDBMS.
Abgesehen davon sind meine Erfahrungswerte an allen Ecken immer nur zu
hoeren, "Ja mit Oracle(ab und zu auch DB2 ;-) ), ja damit kann ich
immense Datenmengen halten, ecc., ecc.". Das entwickelt irgendwann
Eigendynamik.
Grundsaetzlich interessiert mich das dann erst mal garnicht, aber wenn
ich ganz ehrlich bin eben doch.
Deswegen her mit den Erfolgen von ooDBMS.
Frank
Michael Wein
> Michael Wein wrote:
>
>> On Fri, 03 Oct 2003 12:57:47 +0200, Gerd Nachtsheim wrote:
>>
>>>Michael Wein wrote:
>>>
>>>>On Thu, 2 Oct 2003 11:27:17 +0200, Steffen Ramlow wrote:
>>>>
>>>>>* kann sehr große Datenmengen verwalten
>>>>>* skaliert sehr gut
>>>>>* Einbindung anderer Datenquellen
>>>>>* Standard-Schnittstelle (SQL)
>>>>>* sehr ausgereift
>>>>
>>>>Bis auf den Fehler mit SQL beschreibst du die Vorzüge von ODBMS sehr gut.
>>>
>>>Hmmm, hast Du jetzt nicht einen Smiley vergessen? Die Bedeutungslosigkeit von
>>>reinen OODBMS kommt nicht ganz von ungefähr.
>>
>> Nein, habe ich nicht. Welcher der Punkte denkst du denn, treffen auf ODBMS
>> nicht zu? Und bitte Erfahrungswerte, kein "ich hab mal gehört".
>
> Wenn ich's dann mal einfach umdrehen darf heisst das, dass Du
> Erfahrungswerte hast beim
>
> - handling grosser Datenmengen
Ich nicht, aber das Cern:
http://wwwdb.web.cern.ch/wwwdb/objectivity/
Hoffentlich sind die 10 Petabyte groß genug ;-)
> Mich interessieren "Reinfaelle" viel weniger als "Erfolge" beim Einsatz
> reiner ooDBMS.
Ich habe an einem größeren, verteilten kaufmännischen System mitgearbeitet,
das in Java (mit Swing) entwickelt wurde und ein ODBMS zur Datenhaltung
nutzt. Der Zugriff auf die Datenbank war extrem einfach zu realisieren und
erfordert kaum Datenbank-Code in der Applikationslogik (i. W. nur
Transaktioneklammern). So wenig, dass man durch Auskommentieren weniger
Zeilen die Anwendung von persistent auf transient umstellen kann. Derzeit
muss ich mit ORACLE & DB/2 arbeiten; das ist im Vergleich dazu Steinzeit.
--
Michael Wein
Frank Radermacher
> Ich habe an einem größeren, verteilten kaufmännischen System mitgearbeitet,
> das in Java (mit Swing) entwickelt wurde und ein ODBMS zur Datenhaltung
welches?
> nutzt. Der Zugriff auf die Datenbank war extrem einfach zu realisieren und
> erfordert kaum Datenbank-Code in der Applikationslogik (i. W. nur
> Transaktioneklammern). So wenig, dass man durch Auskommentieren weniger
> Zeilen die Anwendung von persistent auf transient umstellen kann. Derzeit
> muss ich mit ORACLE & DB/2 arbeiten; das ist im Vergleich dazu Steinzeit.
Was meinst Du genau mit verteilt?
Frank
Gerd Nachtsheim
Michael Wein wrote:
Ich bezog mich eigentlich auf den 'Fehler mit dem SQL'.
Das war vielleicht ein wenig misverständlich formuliert und sollte wohl heißen
'das Fehlen von SQL Unterstützung', oder?
Wenn man die Diskussionen der letzten zehn Jahre bzgl. 'OODBMS <=> RDBMS' sieht,
dann wurde aus dem 'Fehler mit dem SQL'(das war mal die Lesart der OODBMS
Puristen) das 'Fehlen von SQL'(mit den bekannten Konsequenzen). Insofern hat der
'Fehler mit dem SQL' eine gewisse Doppeldeutigkeit :-)
Soweit mir bekannt, gibt es immer noch kein reines OODBMS, das zeitgemäße SQL
Unterstützung bietet. Da lasse ich mich aber gerne eines besseren belehren, wäre
schön, wenn jemand mit entsprechenden Links helfen könnte.
Gerd, xpost und fup2 de.comp.datenbanken.misc gesetzt
Michael Wein
> Ich bezog mich eigentlich auf den 'Fehler mit dem SQL'.
>
> Das war vielleicht ein wenig misverständlich formuliert und sollte wohl heißen
> 'das Fehlen von SQL Unterstützung', oder?
Ja, das wäre eine bessere Formulierung. Ich bin auch nicht der Meinung,
dass SQL per se ein Fehler ist, im Gegenteil. In der RDBMS-Welt kapselt SQL
die Datenbank ganz gut weg und hilft bei der Abstahierung von dieser.
> Soweit mir bekannt, gibt es immer noch kein reines OODBMS, das zeitgemäße SQL
> Unterstützung bietet.
Das wäre mir auch neu. Ich frage mich aber, ob das wirklich sinnvoll ist,
denn SQL ist auf Tabellen ausgerichtet und das ist bei ODBMS nicht
unbedingt anwendbar. Wenn ich das Pendant von SQL in der ODBMS-Welt nehme,
nämlich OQL, wird dort typischerweise nach Object IDs gefragt und nicht
nach den Attributen eines Objekts, was ja in etwas den Spalten einer
Tabelle entspräche (unter der naiven Annahme, ich könne jedes Objekt in
eine Zeile einer Tabelle "mappen"). Denn der grundlegende Unterschied
besteht darin, dass ich abstrakt nach einem Objekt fragen kann (ohne exakt
dessen "Datentyp" zu kennen), während ich in der RDBMS-Welt das auf
Feld-/Attributebene herunterbrechen muss. Wenn ich aber tatsächlich ein
Objekt zurückerhalte, kann ich dieses entweder direkt nach den gewünschten
Informationen befragen (und im Zweifelsfall kann mir das Objekt diese eher
liefern als das ODBMS) oder sonstiges "wildes" Verhalten des Objekts
nutzen, also Methoden aufrufen. Ein Objekt ist nämlich mehr als die Summe
der Attribute und das "mehr" bekomme ich nur bei einem ODBMS.
Gruß
--
Michael Wein
Michael Wein
> Michael Wein wrote:
>
>> Ich habe an einem größeren, verteilten kaufmännischen System mitgearbeitet,
>> das in Java (mit Swing) entwickelt wurde und ein ODBMS zur Datenhaltung
>
> welches?
Vesant 5.x. Nachdem wir eine Auswahl zwischen Objectstore, objectivity/DB,
Poet, O2, Versant und GemStone gemacht hatten.
> Was meinst Du genau mit verteilt?
Die Datenhaltung war verteilt und mittels asynchroner Replikation wurden
Entitäten bidirektional abgeglichen. Die verschiedenen Applikationsserver
waren zwar auch "verteilt", für sich genommen waren sie aber praktisch
autonom. Sorry wenn das missverständlich war.
--
Michael Wein
J?rgen
> [1] sieht man von den Code-Generatoren Intersystems Caché und Matisse
> ab, die dafür wesentlich schlechter mit bereits bestehenden Klassen
> klar kommen.
Ich weiß ja nicht was die Vertreter der genannten Firmen sagen würden,
aber ich kenne einige Firmen, in denen bei solchen und vorher schon
von Dir getätigten Äußerungen wie "Dafür sind aber die Objekt-Fähigkeiten
dieser beiden Produkte mies." die Rechtsabteilungen spät aber hyperaktiv
zu wirbeln anfangen.
Falls das in Deinem Fall Ende des Jahres immer noch nicht passiert ist,
vermute ich, daß man entweder derzeit gute Gründe hat, Dich zu ignorieren
oder bereits eine unabhängige Evaluation Deines Produktes beauftragt hat,
die alle Schwächen gnadenlos offenlegt ...
Was Dich Deiner derzeitigen Leichtfertigkeit so oder endgültig berauben könnte.
Es gibt sicher Firmen, die in solchen Dingen Skrupel hätten - ich hätte sie
nicht, wenn es um meine Firma ginge ;->
Viel Spaß beim Posten wünscht
der Jürgen
Carl Rosenberger
> > [1] sieht man von den Code-Generatoren Intersystems Caché und Matisse
> > ab, die dafür wesentlich schlechter mit bereits bestehenden Klassen
> > klar kommen.
>
> Ich weiß ja nicht was die Vertreter der genannten Firmen sagen würden,
> aber ich kenne einige Firmen, in denen bei solchen und vorher schon
> von Dir getätigten Äußerungen wie "Dafür sind aber die Objekt-Fähigkeiten
> dieser beiden Produkte mies." die Rechtsabteilungen spät aber hyperaktiv
> zu wirbeln anfangen.
Aha.
Ist denn etwas falsch an dem, was ich schreibe?
Wenn ja, was?
> Falls das in Deinem Fall Ende des Jahres immer noch nicht passiert ist,
> vermute ich, daß man entweder derzeit gute Gründe hat, Dich zu ignorieren
> oder bereits eine unabhängige Evaluation Deines Produktes beauftragt hat,
> die alle Schwächen gnadenlos offenlegt ...
Ich wäre definitiv der Meinung, daß die Firmen besseres zu tun
haben als sich auf allerlei Geplänkel wegen Newsgroup-Postings
einzulassen.
Welchen positiven Nutzen könnten sie davon haben, außer schlechter
publicity?
Du schreibst wesentlich schärfere Kritik über Matisse, wie ich lese:
http://www.google.de/groups?selm=3F3FC7D0.80305%40freenet.de
Eine Äußerung "Ich glaube nicht, daß diese Firma überlebt..." finde
ich unsachlich und unbegründet, solange man nicht Internas über
Kundenstamm, Aufträge, Kosten und Umsatz einer Firma weiß. Kennst Du
all diese Daten über Matisse?
Warum hast Du keine Angst vor rechtlichen Konsequenzen, wenn Du sowas
schreibst?
Viele Grüße,
Carl
Gerd Nachtsheim
> J?rgen <jkin...@freenet.de> wrote:
>
>>>[1] sieht man von den Code-Generatoren Intersystems Caché und Matisse
>>>ab, die dafür wesentlich schlechter mit bereits bestehenden Klassen
>>>klar kommen.
>>
>>Ich weiß ja nicht was die Vertreter der genannten Firmen sagen würden,
>>aber ich kenne einige Firmen, in denen bei solchen und vorher schon
>>von Dir getätigten Äußerungen wie "Dafür sind aber die Objekt-Fähigkeiten
>>dieser beiden Produkte mies." die Rechtsabteilungen spät aber hyperaktiv
>>zu wirbeln anfangen.
>
>
> Aha.
>
> Ist denn etwas falsch an dem, was ich schreibe?
Du solltest aufhören, vergleichende Werbung zu machen, wenn Du die Produkte
nicht mal richtig kennst.
Gerd
Carl Rosenberger
> > Läuft db4o eigentlich unter Mono?
>
> - FileStream.Lock() wird von Mono noch nicht unterstützt. Das kann
> man in db4o in ../src/net/Compat#lockFileStream() abschalten, indem
> man die Zeile
> fs.Lock(0, 1);
Ich habe gerade nochmal mit dem neuen 0.28er Release von Mono
getestet. FileStream.Lock() gibt es immer noch nicht, ansonsten
geht jetzt alles. (bis auf eine eigenartige Fehlermeldung bei
der Socket-Verbindung, die aber keine negative Auswirkung hat)
Mono ist in diesem Release um Welten schneller geworden und kommt
jetzt unter Windows fast an die Geschwindigkeit von MS .NET heran.
Carl Rosenberger
> >>>[1] sieht man von den Code-Generatoren Intersystems Caché und Matisse
> >>>ab, die dafür wesentlich schlechter mit bereits bestehenden Klassen
> >>>klar kommen.
> >
>
> Du solltest aufhören, vergleichende Werbung zu machen,
Tue ich das?
Ich schreibe lediglich meine private Meinung über die Produkte,
soweit ich über sie Bescheid weiß.
> wenn Du die Produkte nicht mal richtig kennst.
Ich wiederhole nochmal:
Was ist an dem falsch, was ich geschrieben habe?
Ich habe im März eine 5.0.0 Version von Caché evaluiert.
(Build 480U_SU)
Du kennst Dich mit diesem Produkt sicher sehr viel besser
aus als ich. Angenommen ich habe folgende Klasse:
public class Foo{
String bar;
}
Wie kann ich ein Objekt dieser Klasse mit der Caché Version,
die ich habe, persistent machen?
Angenommen ich möchte die Klasse danach weiter mit Eclipse
editieren und ein neues Feld hinzufügen. Wie mache ich das
mit der Caché Version, die ich hier habe?
Hat sich bei der Funktionalität inzwischen etwas getan?
Auf der Intersystems Seite sehe ich, daß es inzwischen
eine 5.0.3 Version gibt. Von der "3" hinter dem letzten Komma
erwarte ich keine großen Neuerungen oder liege ich da falsch?
Viele Grüße,
Carl
Marcus Fihlon
>Du solltest aufhören, vergleichende Werbung zu machen, wenn Du die Produkte
>nicht mal richtig kennst.
Nur mal so nebenbei, damit ich auch mal wieder meinen Senf dazugeben
kann: Vergleichende Werbung ist nach EU-Recht, das auch in DE
rechtskräftig umgesetzt wurde, erlaubt (Richtlinie 97/55/EG; § 2 UWG,
der mit Wirkung zum 14.09.2000 durch Gesetz vom 01.09.2000 in das UWG
eingefügt wurde).
*schnatter*
Marcus
--
"Dann schreib das doch bzw. verhalte Dich so. Wie man in die Newsgroup
hineinkräht, so ei-duziduzidu-t es wieder raus."
Dirk Nimmich (de.comp.datenbanken.mysql)
Juergen Kindler
Carl Rosenberger wrote:
> Aha.
>
> Ist denn etwas falsch an dem, was ich schreibe?
> Wenn ja, was?
Um es mal kurz zu sagen: Du überschreitest die Grenzen dessen, was
bei vergleichender Werbung erlaubt ist. Als Mitinhaber einer Firma
dessen Urposting noch oben im Titel steht, hast Du nicht die Möglich-
keit, Dich auf "private Meinungsäußerung" zurückzuziehen.
Offensichtlich ist Dir das nicht klar.
> Ich wäre definitiv der Meinung, daß die Firmen besseres zu tun
> haben als sich auf allerlei Geplänkel wegen Newsgroup-Postings
> einzulassen.
Das ist eine Hoffnung, die sich nur dann erfüllt, wenn man unbedeutend
genug erscheint, um nicht überrollt zu werden.
> Welchen positiven Nutzen könnten sie davon haben, außer schlechter
> publicity?
Zu verhindern, daß Konkurrenten Meinungsmache betreiben und falsche
Aussagen über andere Produkte verbreiten.
> Du schreibst wesentlich schärfere Kritik über Matisse, wie ich lese:
> http://www.google.de/groups?selm=3F3FC7D0.80305%40freenet.de
> Eine Äußerung "Ich glaube nicht, daß diese Firma überlebt..." finde
> ich unsachlich und unbegründet, solange man nicht Internas über
> Kundenstamm, Aufträge, Kosten und Umsatz einer Firma weiß. Kennst Du
> all diese Daten über Matisse?
>
> Warum hast Du keine Angst vor rechtlichen Konsequenzen, wenn Du sowas
> schreibst?
0. Verfälschst Du meine Aussage, um sie gegen mich zu verwenden.
1. Bin ich eine Privatperson und kein Konkurrent dieser Firma.
2. Habe ich deutlich auf die (IMHO) Fehlkonzeptionen des Systems
hingewiesen und meine Privatmeinung mit genau diesen inhärenten
Problemen verknüpft.
3. Kannst Du ja die Geschichte anderer OO-Datenbanken im immer enger
werdenden OO-Datenbankmarkt auch selbst überblicken und die
Lebenszeit der noch verbleibenden Wettbewerber extrapolieren ;-]
4. Möchtest Du wirklich, daß ich Dein Produkt technisch evaluiere
und Dir ein paar Benchmarks schreibe, die die Schwächen Deines
Systems klar zu Tage treten lassen?
Mit Datenbanken und insbesondere Datenbanktheorie kenne ich mich
ebenso gut aus wie mit Implementierungstechniken und tatsächlicher
Implementierung. Ehrlich gesagt, habe ich aber kein gesteigertes
Interesse daran ... ich kenne interessantere Herausforderungen.
Bye
Jürgen
Gerd Nachtsheim
> Gerd Nachtsheim wrote:
>
>>>>>[1] sieht man von den Code-Generatoren Intersystems Caché und Matisse
>>>>>ab, die dafür wesentlich schlechter mit bereits bestehenden Klassen
>>>>>klar kommen.
> Ich schreibe lediglich meine private Meinung über die Produkte,
> soweit ich über sie Bescheid weiß.
Schön wärs.
> Ich wiederhole nochmal:
> Was ist an dem falsch, was ich geschrieben habe?
[Carl fragt: Wie macht man mit Caché+Eclipse Javaklassen persistent?]
Nur, weil *Du* nicht weißt, wie etwas funktioniert, heißt das noch lange nicht,
daß es dieses Feature nicht gibt.
Wenn Du Fragen zu fremden Datenbankprodukten hast, solltest Du Dich direkt an
den Hersteller Deines Vertrauens ;) wenden oder in den einschlägigen
Datenbank-NG posten. Das ist hilft Dir sicher mehr als hier im Nebel Deiner
eigenen Halbwahrheiten nach dem rettenden Ufer zu suchen.
Gerd Nachtsheim
> Gerd Nachtsheim <ge...@users.sourceforge.net> schrieb:
>
>
>>Du solltest aufhören, vergleichende Werbung zu machen, wenn Du die Produkte
>>nicht mal richtig kennst.
>
>
> Nur mal so nebenbei, damit ich auch mal wieder meinen Senf dazugeben
> kann: Vergleichende Werbung ist nach EU-Recht, das auch in DE
> rechtskräftig umgesetzt wurde, erlaubt (Richtlinie 97/55/EG; § 2 UWG,
> der mit Wirkung zum 14.09.2000 durch Gesetz vom 01.09.2000 in das UWG
> eingefügt wurde).
Korrekt, das ist aber noch lange kein Freibrief zum Miesmachen und
Gerüchteverbreiten.
Wer Mist erzählt, und anderen damit schadet, kann zur Rechenschaft gezogen werden.
Carl Rosenberger
> > Ich wiederhole nochmal:
> > Was ist an dem falsch, was ich geschrieben habe?
>
> [Carl fragt: Wie macht man mit Caché+Eclipse Javaklassen persistent?]
>
> Nur, weil *Du* nicht weißt, wie etwas funktioniert, heißt das noch lange nicht,
> daß es dieses Feature nicht gibt.
Ich behaupte: (solange bis mich jemand korrigiert)
Um Java Klassen persistent zu machen, leitet man mit Caché
üblicherweise von der Klasse "Persistent" ab. Ein Objekt einer
x-beliebigen Klasse lässt sich also nicht abspeichern, ohne die
Klassendefinition speziell für Caché abzuändern.
Das "normale" Vorgehen mit Caché ist, sich die Java Klassen aus
dem proprietären Caché Datenbankschema generieren zu lassen.
Deswegen nenne ich Caché (genau wie Matisse auch, das nach dem
selben Prinzip operiert) einen "Code-Generator".
Wenn man nachträglich ein Feld in eine solche generierte Klasse
einbaut, wird das nicht automatisch auch gespeichert.
Eine für Caché persistierbar gemachte Klasse enthält eine ganze
Menge zusätzlichen Code von Caché, um die Interaktion mit der
Datenbank zu regeln. Angesichts der Menge der Methoden erscheint
eine manuell Pflege dieser Methoden nicht sinnvoll.
In der mir vorliegenden Version habe ich kein Tool erkannt, daß
es mir ermöglicht hätte, simpel mit Eclipse meine Klassen zu
ergänzen und zu refakturieren und die Pflege des Datenbankschemas
durch ein Tool von Intersystems automatisch regeln zu lassen. Das
können andere Objektdatenbanksysteme besser, nämlich vollautomatisch.
Aus diesem Grund stehe ich zu der Aussage die ich oben getroffen
habe:
"[1] sieht man von den Code-Generatoren Intersystems Caché und Matisse
ab, die dafür wesentlich schlechter mit bereits bestehenden Klassen
klar kommen."
Ich halte diese Aussage für völlig objektiv und richtig, weil
beweisbar. Wenn jemand anderer Meinung ist, soll er Fakten auf
den Tisch legen, warum.
Viele Grüße,
Carl
Paul Ebermann
> Gerd Nachtsheim <ge...@users.sourceforge.net> schrieb:
>
> >Du solltest aufhören, vergleichende Werbung zu machen, wenn Du die Produkte
> >nicht mal richtig kennst.
>
> Nur mal so nebenbei, damit ich auch mal wieder meinen Senf dazugeben
> kann: Vergleichende Werbung ist nach EU-Recht, das auch in DE
> rechtskräftig umgesetzt wurde, erlaubt (Richtlinie 97/55/EG; § 2 UWG,
> der mit Wirkung zum 14.09.2000 durch Gesetz vom 01.09.2000 in das UWG
> eingefügt wurde).
<http://www.rolfbecker.de/wettbewerbsrecht/vergleichendewerbung.htm#Vergleichende Werbung>
Der Paragraph regelt vor allem, wann vergleichende
Werbung sittenwiedrig ist.
Die Frage ist, ob Carl hier überhaupt Werbung macht.
Paul
Gerd Nachtsheim
[...]
> Aus diesem Grund stehe ich zu der Aussage die ich oben getroffen
> habe:
>
> "[1] sieht man von den Code-Generatoren Intersystems Caché und Matisse
> ab, die dafür wesentlich schlechter mit bereits bestehenden Klassen
> klar kommen."
> Ich halte diese Aussage für völlig objektiv und richtig, weil
> beweisbar. Wenn jemand anderer Meinung ist, soll er Fakten auf
> den Tisch legen, warum.
Mach Dir doch das Leben nicht so unendlich schwer, Carl. Du hast eine
Behauptung[1] über Konkurrenzprodukte aufgestellt, die Du nicht beweisen kannst.
Dabei bist Du erwischt worden und drehst Dich nun im Kreis und stampfst mit dem
Fuss auf, wie ein kleines Kind.
Und jetzt meinst Du, die anderen[tm] sollten hier in dclj auflaufen und Dir das
Gegenteil beweisen.
Na dann noch viel Spaß beim Warten :-)
Bernd Eckenfels
> Wer Mist erzählt, und anderen damit schadet, kann zur Rechenschaft gezogen werden.
Nun ja, so generell wuerde ich das nicht unterschreiben. Allerdings Hat Carl
noch keiner Mist nachgewiesen. Wir sind hier im Usenet, bevor man Carl
verklagt sollte man es mal mit nem F'up probieren.
Gruss
Bernd
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
Gerd Nachtsheim
> Gerd Nachtsheim <ge...@users.sourceforge.net> wrote:
>
>>Wer Mist erzählt, und anderen damit schadet, kann zur Rechenschaft gezogen werden.
>
>
> Nun ja, so generell wuerde ich das nicht unterschreiben. Allerdings Hat Carl
> noch keiner Mist nachgewiesen. Wir sind hier im Usenet, bevor man Carl
> verklagt sollte man es mal mit nem F'up probieren.
Oh je... ich hatte sicher nicht vor, Carl zu verklagen.
Ich wollte nur deutlich machen, daß auch vergleichende Werbung nicht irgendeinen
Schwachfug behaupten darf. Das Scharmützel um Carl's fragwürdige Behauptungen
war eher der zufällige Aufhänger.
Carl Rosenberger
> Mach Dir doch das Leben nicht so unendlich schwer, Carl. Du hast eine
> Behauptung[1] über Konkurrenzprodukte aufgestellt, die Du nicht beweisen kannst.
> Dabei bist Du erwischt worden und drehst Dich nun im Kreis und stampfst mit dem
> Fuss auf, wie ein kleines Kind.
>
> Und jetzt meinst Du, die anderen[tm] sollten hier in dclj auflaufen und Dir das
> Gegenteil beweisen.
>
> Na dann noch viel Spaß beim Warten :-)
Gerd,
Dein Posting besteht aus nichts anderem als aus einer persönlichen
Beleidigung.
Was soll das?
Wobei bin ich erwischt worden?
Wo sind die Fakten?
Wo erzähle ich Mist, wie Du in einem anderen Posting behauptest?
Nochmal ganz kurz, nur für Dich:
Ich behaupte, Caché Version 5.0 kann keine Java Objekte abspeichern,
ohne vorher in Java Klassen eigenen Code einzubauen. Ich kenne ein
Produkt, bei dem das nicht notwendig ist. Dieses Produkt ist in dieser
Hinsicht überlegen.
Das beweist meine Behauptung.
Als Repräsentant von Intersystems solltest Du sehr genau wissen, was
Caché kann und was nicht. Demnach sollte es Dir ein leichtes sein,
meine Behauptung zu widerlegen, falls das möglich ist.
Viele Grüße,
Carl
Gerd Nachtsheim
> Dein Posting besteht aus nichts anderem als aus einer persönlichen
> Beleidigung.
Bleib mal locker, keiner will Dich hier beleidigen...
> Nochmal ganz kurz, nur für Dich:
> Ich behaupte, Caché Version 5.0 kann keine Java Objekte abspeichern,
> ohne vorher in Java Klassen eigenen Code einzubauen. Ich kenne ein
> Produkt, bei dem das nicht notwendig ist. Dieses Produkt ist in dieser
> Hinsicht überlegen.
Keine mir bekannte Datenbank macht das so(ohne den Code zu verändern), wie
dieses "Produkt, das Du kennst", insofern ist das "Produkt, das Du kennst",
*allen* anderen 'überlegen'.
Ich stimme aber /hiermit/ nicht überein
| Von den noch (O2 ist kaputt) lebendigen Produkten sind POET und
| Versant bei SQL-Fähigkeiten klar am weitesten [1].
[...]
| [1] sieht man von den Code-Generatoren Intersystems Caché und Matisse
| ab, die dafür wesentlich schlechter mit bereits bestehenden Klassen
| klar kommen.
Das hast Du gepostet und diese Ansicht teile ich nicht. Caché (ich kann nicht
für Matisse sprechen) kann hervorragend mit bestehenden Klassen umgehen.
Auch gibt es eine API zum Importieren existierender Java Klassen als Metadaten,
die dann in Caché als persistente Klassen abgebildet werden. Der Zugriff erfolgt
dann wiederum über den generierten Java Code. Also kann Caché auch mit
bestehenden Java Klassen 'umgehen'. Nur eben nicht genauso, wie Du es von
*Deinem* Produkt gewohnt bist. Daraus leitest Du ein 'schlechter klarkommen' ab,
und ich eben nicht.
Und dabei sollten wir es auch belassen
Gerd, dem die Lust auf Diskutieren mit Dir total vergangen ist
Frank Radermacher
> Gerd Nachtsheim wrote:
> Dein Posting besteht aus nichts anderem als aus einer persönlichen
> Beleidigung.
> Als Repräsentant von Intersystems solltest Du sehr genau wissen, was
> Caché kann und was nicht. Demnach sollte es Dir ein leichtes sein,
> meine Behauptung zu widerlegen, falls das möglich ist.
Wer zurueckschiesst hat trotzdem geschossen.
Frank
Frank Radermacher
> Carl Rosenberger wrote:
>
>> Dein Posting besteht aus nichts anderem als aus einer persönlichen
>> Beleidigung.
>
> Bleib mal locker, keiner will Dich hier beleidigen...
Ich persoenlich nehme Dir das "will" sogar ab, unabhaengig davon, war
Dein post jedoch unnoetig persoenlich sehr "geladen".
>> Nochmal ganz kurz, nur für Dich:
>> Ich behaupte, Caché Version 5.0 kann keine Java Objekte abspeichern,
>> ohne vorher in Java Klassen eigenen Code einzubauen. Ich kenne ein
>> Produkt, bei dem das nicht notwendig ist. Dieses Produkt ist in dieser
>> Hinsicht überlegen.
>
> Keine mir bekannte Datenbank macht das so(ohne den Code zu verändern),
> wie dieses "Produkt, das Du kennst", insofern ist das "Produkt, das Du
> kennst", *allen* anderen 'überlegen'.
>
Jetzt ist es klarer.
> Ich stimme aber /hiermit/ nicht überein
>
> | Von den noch (O2 ist kaputt) lebendigen Produkten sind POET und
> | Versant bei SQL-Fähigkeiten klar am weitesten [1].
An dieser Stelle habe auch ich Cacké vermisst, weil ich einige
Installationen kenne, bei denen Caché (sehr erfolgreich) als reine SQL
Datenbank eingesetzt wird.
>
> | [1] sieht man von den Code-Generatoren Intersystems Caché und Matisse
> | ab, die dafür wesentlich schlechter mit bereits bestehenden Klassen
> | klar kommen.
>
An dieser Stelle haette ich mich ueber den jetzt erst folgenden Hinweis
gefreut.
> Das hast Du gepostet und diese Ansicht teile ich nicht. Caché (ich kann
> nicht
> für Matisse sprechen) kann hervorragend mit bestehenden Klassen umgehen.
>
> Auch gibt es eine API zum Importieren existierender Java Klassen als
> Metadaten,
> die dann in Caché als persistente Klassen abgebildet werden.
Heisst API ich muss ein Programm zum Import schreiben oder ist es ein
Knopf im Configuration Manager?
> Der Zugriff erfolgt
> dann wiederum über den generierten Java Code. Also kann Caché auch mit
> bestehenden Java Klassen 'umgehen'. Nur eben nicht genauso, wie Du es von
> *Deinem* Produkt gewohnt bist. Daraus leitest Du ein 'schlechter
> klarkommen' ab, und ich eben nicht.
Stimmt es, dass auch bei Caché mit Reflection "gespielt" worden ist?
>
> Und dabei sollten wir es auch belassen
Waere schade. Mich wuerde interessieren von reinen oder vorwiegend
Javainstallationen zu hoeren, bei denen Caché eingesetzt wird.
Frank
J?rgen
> Die Frage ist, ob Carl hier überhaupt Werbung macht.
Die Frage kannst Du Dir selbst beantworten, indem Du den Titel dieses
Threads liest. Er befindet sich (insbesondere als Firmengründer und
Mitinhaber der Firma db4o) hier ganz klar in einer Marketing-Situation
und gebraucht diese News-Group als Plattform für Eigenwerbung.
Nebenher greift er mit denkbar dünnen Argumenten Produkte an, mit denen
er konkurrieren will. Ohne das aber im Einzelnen analysieren zu müssen:
die spielen in einer ganz anderen Liga und haben es nicht nötig sich
damit herauszureden, daß ein dokumentiertes Feature ja nur experiementell
sei und so weiter und so heiter...
In den passenderen Datenbank-Gruppen hat er damit wenig Akzeptanz
gefunden - über die Gründe mag sich jeder selbst ein Bild machen; ich
muß das nicht kommentieren.
Weiterhin viel Spaß wünscht
Jürgen
Gerd Nachtsheim
> Gerd Nachtsheim wrote:
>> Bleib mal locker, keiner will Dich hier beleidigen...
> Ich persoenlich nehme Dir das "will" sogar ab, unabhaengig davon, war
> Dein post jedoch unnoetig persoenlich sehr "geladen".
Ich hatte nicht vor, Carl oder sonstwen persönlich zu beleidigen. Tut mir leid,
wenn das so angekommen ist, meine 'Ladung' war sicher unüberlesbar :)
>>> Nochmal ganz kurz, nur für Dich:
>>> Ich behaupte, Caché Version 5.0 kann keine Java Objekte abspeichern,
>>> ohne vorher in Java Klassen eigenen Code einzubauen. Ich kenne ein
>>> Produkt, bei dem das nicht notwendig ist. Dieses Produkt ist in dieser
>>> Hinsicht überlegen.
>>
>>
>> Keine mir bekannte Datenbank macht das so(ohne den Code zu verändern),
>> wie dieses "Produkt, das Du kennst", insofern ist das "Produkt, das Du
>> kennst", *allen* anderen 'überlegen'.
>>
> Jetzt ist es klarer.
Ja, sieht auch heute morgen noch klarer aus :-)
> Heisst API ich muss ein Programm zum Import schreiben oder ist es ein
> Knopf im Configuration Manager?
Es gibt (ab 5.0.3(?))
com.intersys.cache.CacheClassGenerator (aus dem Gedächtnis...)
die dafür vorgesehen ist. Sie ist noch nicht offiziell Bestandteil des
Produktes, wurde aber schon von einigen Kunden/Interessenten genutzt wurde, um
ihre bestehenden Modelle von Java nach Caché zu bringen.
> Stimmt es, dass auch bei Caché mit Reflection "gespielt" worden ist?
siehe eins weiter oben
Gruß
Gerd
Carl Rosenberger
> > Dein Posting besteht aus nichts anderem als aus einer persönlichen
> > Beleidigung.
>
> Bleib mal locker, keiner will Dich hier beleidigen...
Sowohl den Vergleich mit einem herumhüpfenden Kind als auch die
zunächst unsubstantiierte Aussage "Carl erzählt Mist" entspricht
nicht Deinem normalerweise sehr hohen Diskussionsniveau und
deswegen habe ich mich gewundert.
> > Nochmal ganz kurz, nur für Dich:
> > Ich behaupte, Caché Version 5.0 kann keine Java Objekte abspeichern,
> > ohne vorher in Java Klassen eigenen Code einzubauen. Ich kenne ein
> > Produkt, bei dem das nicht notwendig ist. Dieses Produkt ist in dieser
> > Hinsicht überlegen.
>
> Keine mir bekannte Datenbank macht das so(ohne den Code zu verändern), wie
> dieses "Produkt, das Du kennst", insofern ist das "Produkt, das Du kennst",
> *allen* anderen 'überlegen'.
Eine ganze Reihe von Firmen bieten Möglichkeiten an, ihren
Bytecode-Enhancer in gängige Java Entwicklungsumgebungen wie
Eclipse und Netbeans zu integrieren. Auch darunter verstehe
ich "gut mit bestehenden Klassen umgehen".
> | Von den noch (O2 ist kaputt) lebendigen Produkten sind POET und
> | Versant bei SQL-Fähigkeiten klar am weitesten [1].
Um das im Nachhinein klar zu stellen:
Mit Caché bekommt man eine hervorragende schnelle ausgereifte
SQL Datenbank, bei der die Bezeichnung "SQL" auch wirklich
berechtigt ist. Daß ich Caché in Punkto SQL für überlegen halte,
ist implizit in meinem nächsten Statement enthalten (siehe unten).
Ich weiß also gar nicht, worüber Du Dich aufregst, Gerd.
> | [1] sieht man von den Code-Generatoren Intersystems Caché und Matisse
> | ab, die dafür wesentlich schlechter mit bereits bestehenden Klassen
> | klar kommen.
>
> Das hast Du gepostet und diese Ansicht teile ich nicht. Caché (ich kann nicht
> für Matisse sprechen) kann hervorragend mit bestehenden Klassen umgehen.
>
> Auch gibt es eine API zum Importieren existierender Java Klassen als Metadaten,
> die dann in Caché als persistente Klassen abgebildet werden. Der Zugriff erfolgt
> dann wiederum über den generierten Java Code. Also kann Caché auch mit
> bestehenden Java Klassen 'umgehen'. Nur eben nicht genauso, wie Du es von
> *Deinem* Produkt gewohnt bist. Daraus leitest Du ein 'schlechter klarkommen' ab,
> und ich eben nicht.
Ich bleibe dabei, daß diese Art mit bestehenden Klasse umzugehen
schlechter funktioniert als bei vielen der anderen Produkte:
Selbst wenn es existierenden Java Code gibt, ist die Verwendung
umständlich, weil folgende drei Schritte notwendig sind:
- Analyse des Java Codes
- Erzeugung des Caché Schemas
- Erneute Erzeugung des Java Codes
Was macht man mit Klassen, deren Quellcode man nicht hat?
Was macht man mit Klassen, die von JDK Klassen abgeleitet sind?
Wie lange dauert das?
Wo klinkt man das CVS ein?
Wie würde man mit AspectJ arbeiten?
Wie sieht der Code danach im Debugger aus?
Wie bequem ist es, wenn man schnell mal eben während der Entwicklung
ein einziges Feld hinzufügen will?
Andere Produkte klinken sich direkt in die Entwicklungsumgebung
ein um den Bytecode zu verändern und man hat deutlich weniger
Sorgen, um sich um Persistenz zu kümmern. Ein Produkt kommt völlig
ohne Veränderung der Klassen aus.
Ich stehe absolut zu der Aussage "wesentlich schlechter mit bereits
bestehenden Klassen klar kommen".
Vielleicht habe ich die ursprüngliche Formulierung unglücklich gewählt,
indem ich Caché bei SQL nur in einem Nebensatz erwähnt habe.
Viele Grüße,
Carl
Gerd Nachtsheim
> Sowohl den Vergleich mit einem herumhüpfenden Kind als auch die
> zunächst unsubstantiierte Aussage "Carl erzählt Mist" entspricht
> nicht Deinem normalerweise sehr hohen Diskussionsniveau und
> deswegen habe ich mich gewundert.
Meinst Du vielleicht <blv7o6$tp$02$1...@news.t-online.com>?
Dort steht aber gar nicht "Carl erzählt Mist" sondern
| [...]
| Korrekt, das ist aber noch lange kein Freibrief zum Miesmachen und
Gerüchteverbreiten.
| Wer Mist erzählt, und anderen damit schadet, kann zur Rechenschaft gezogen werden.
Gerd
Marco Lange
> Ich habe gerade nochmal mit dem neuen 0.28er Release von Mono
> getestet. FileStream.Lock() gibt es immer noch nicht, ansonsten
> geht jetzt alles. (bis auf eine eigenartige Fehlermeldung bei
> der Socket-Verbindung, die aber keine negative Auswirkung hat)
>
> Mono ist in diesem Release um Welten schneller geworden und kommt
> jetzt unter Windows fast an die Geschwindigkeit von MS .NET heran.
Vielen Dank, Carl, für die Tests unter Mono. Ich denke nicht zuletzt für
Dich ist die Lauffähigkeit Deines Produktes unter Mono vorteilhaft.
Ich persönlich halte Mono für ein großartiges Projekt, wenn auch auch
noch im Anfangsstadium ist. Know-How steckt mit Ximian und Manuel De
Icaza definitiv dahinter. Ich hoffe nur, dass MS Mono nicht irgendwann
die Patentschlinge um den Hals wirft.
Viele Grüße,
Marco
Carl Rosenberger
> Könntest du mir das Template JClass.jgt bitte direkt an meine
> Email-Adresse senden? Ich werde mir auch die Dateien im sql-Package
> alle ansehen, weil mir weiter aufgefallen ist, dass weder Statements
> noch ResultSet's je geschlossen werden. Sobald ich damit fertig bin,
> diesbezüglich Anpassungen vorzunehmen und meine Erfahrungen im
> Bereich JDBC auf RDBMS einzubringen, werde ich dir die geänderten
> Dateien in diesem Package per Email schicken.
Hallo Andree,
ein kleiner Nachtrag dazu:
Dank Deiner Anregung wurde etwas Zeit investiert, um das
Feature zu verbessern. Diese Datei ist im aktuellen Download
jetzt nicht mehr notwendig.
Als Compiler wird jetzt auch javac direkt aufgerufen, wenn
sich die tools.jar im CLASSPATH befindet, ohne Umweg über
Runtime#exec().
Nochmal vielen Dank für Deine konstruktive Kritik. Weitere
Kritik ist ganz herzlich willkommen.
Viele Grüße,
Carl