Resultset will in While nur EINMAL liefern!

[qeldroma]

Erstmal die Code-Snipplets:

Aufruf:

	public static void main(String[] args) throws Exception {
		Connection oConnection;
		Class.forName("org.gjt.mm.mysql.Driver");
		oConnection = DriverManager.getConnection("jdbc:mysql://....");
		String Mandant="Blafusel";
		int uid=1003;
		DatabaseManager dbBackend = new DatabaseManager(oConnection, uid,false);
		User actUser = new User(uid,dbBackend);
		System.out.println(actUser);
	}

Der "User":

public class User {
	DatabaseManager dbBackend;
	public User(int uid,DatabaseManager dbBackend) throws Exception{
				this.uid = uid;
				this.dbBackend= dbBackend;
				this.load();
	}

	public void load() throws Exception{
		ResultSet dummy = dbBackend.getDomains(this.uid);
		while (dummy.next()) domains.add(new Domain(dummy.getString("name"),dbBackend));
		dummy.close();
	}
}

..und dbBackend.getDomains(uid):

	public ResultSet getDomains(int uid) throws SQLException {
		String dummy="SELECT domains.name,isActive FROM domains WHERE domains.users_uid="+uid+";";
		if(debug)write("----------------------------------------------------------------\nMethod: getDomains()\n"+dummy);
		return oStatement.executeQuery(dummy);
	}

Nun, was passiert ist folgendes:

Anhand der UserID sollen alle dazugehörigen Domains ausgelesen werden. Das sind in diesem Falle drei.

Tatsächlich kommt bei Zeile 9 (2. Teil) auch ein Resultset an, welches laut Debugger ein "elementCount" von 3 hat und auch in "elementData" in den ersten drei Einträgen gefüllt ist, will heißen, beim ersten Eintauchen in die Schleife ist das Resultset so, wie erwartet.

Nun "steppe" ich im Debugger weiter, der Debugger springt zurück auf "while" und plötzlich, genau jetzt, ist "elementCount" aus heiterem Himmel auf null gesetzt, weswegen die Schleife somit nicht mehr weiterrennt....

Was denkt ihr?

 

[foobar]

Nun "steppe" ich im Debugger weiter, der Debugger springt zurück auf "while" und plötzlich, genau jetzt, ist "elementCount" aus heiterem Himmel auf null gesetzt, weswegen die Schleife somit nicht mehr weiterrennt....

Wird eine Exception geworfen oder bekommst du nicht das erwartete Ergebnis?

 

[akira]

Du solltest irgendwie besser zwischen reinen Datenobjekten und Zugriffsobjekten trennen.

Du übergibst dem User-Objekt die Datenbank-Connection und erzeugst dann weitere Unterobjekte (Domain) und übergibst denen auch die Instanz. Das ist vom Design her erstmal nicht so toll.

Was machst Du denn im Domain-Konstruktor noch so alles mit dem einen Statement ?

Laut API kann es pro Statement immer nur ein gültiges ResultSet geben:

By default, only one ResultSet object per Statement object can be open at the same time.

 

[qeldroma]

Du solltest irgendwie besser zwischen reinen Datenobjekten und Zugriffsobjekten trennen.
Du übergibst dem User-Objekt die Datenbank-Connection und erzeugst dann weitere Unterobjekte (Domain) und übergibst denen auch die Instanz. Das ist vom Design her erstmal nicht so toll.

Tja, das ist mein wunder Punkt, ich musste alleine designen, nur mit Büchern ausgestattet, obwohl ich bisher nur kleine Applikationen geschrieben habe. Konnte mich auch nicht dagegen wehren ;-)
Aber dafür bin ich umso lernbereiter, wenn du mir hwlfwn möchtest :autsch:

Grundsätzlich habe ich ein drei-Schicht-Modell entwickelt:
1. Ausführende Schicht. Diese ist im direkten Zugriff durch den Tomcat-Webserver
2. Modell-Schicht. Diese repräsentiert das Datenmodell und enthält die Logik.
3. Backend-Schicht. Diese enthält drei Klassen: Eine pro Datenhaltung, in dem Fall also eine für eine MySQL-Datenbank, eine für eine XML-Schnittstelle, etc...

Also, ich sollte also nur im dbBackend die komplette Connection behandeln. Ok. Brauche ich ja nur verlagern. Dachte in der 1. Schicht sei das besser aufgehoben.

Da mein Modell auch auf dieses Backend zugreifen muß, dachte ich, es wäre am einfachsten in der ausführenden Schicht ein zentrales "Datenbank-Backend-Objekt" zu erzeugen und dieses einfach durchzureichen, so daß alle Unterobjekte das gleiche Datenbankobjekt benutzen?

Ich habe wohl dann auch nicht so recht verstanden, was denn tatsächlich ein "Statement" ist. Ich dachte ich könnte tatsächlich für alle Abfragen ein und dasselbe Statement nehmen...?

Grüße, qd

 

[akira]

Dein 3-Schicht-Modell ist soweit schon in Ordnung, die Datenobjekte sollten jedoch entkoppelt von ihrer Erzeugung sein.

Benutze besser z.B. spezielle Factory-Klassen, die Objekte eines bestimmten Typs erzeugen, d.h eine DB-Connection zu erzeugen, die Abfrage durchzuführen, ein Daten-Objekt zu erzeugen und die setter-Methoden mit den Werten des ResultSets zu befüllen.

Ein Datenbank-Zugriff sieht in der Regel so aus:

1. Connection anfordern
2. ggf. Transaktion starten
3. ein Statement erzeugen
4. entweder Query oder Update ausführen
5. bei Query ResultSet schließen
6. Statement schließen
.. Punkt 3-6 beliebig oft wiederholbar
7. ggf. Transaktion beenden
8. Connection schließen

Für die genannte Factory-Klasse(n) bietet sich das Singleton-Pattern an. Du hast somit von jeder Klasse aus Zugriff auf die Datenhaltung. In der einen Singleton-Instanz erzeugst Du am besten einen ConnectionPool und forderst für jede Methode, z.B. getDomains(..) eine Connection an und gibst diese am Ende der Methode an den Pool zurück.

 

[Bleiglanz]

anders gesagt:

dein Modell-Objekt "User" sollte keine Methoden haben wie load(), store() usw., weil du dann alles mit Datenbank-Code verunreinigst und immer die connection herumreichen musst. Solche Objekte sollen keine Ahnung davon haben, wie und wo sie persistent gemacht werden.

schreib dir lieber eine Klasse [sagen wir DataStore? als Singleton? Connection im Konstruktor übergeben? ...], die den ganzen Zeug "abstrahiert", so nach dem Motto

User u = dataStore.loadUser(int id)
// mach was
boolean success = dataStore.updateUser(u);
User v = new User();
dataStore.insertUser(v);

usw.

 

[qeldroma]

Ok, ich muß jetzt erstmal eine Weile kauen, damit ich die Stücke auch schlucken kann :###

Aber ich danke euch schon mal so weit, auch wenn ich mir ziemlich sicher bin hier gleich wieder was hinterherzuschieben ???:L

 

[qeldroma]

...dein Modell-Objekt "User" sollte keine Methoden haben wie load(), store() usw., weil du dann alles mit Datenbank-Code verunreinigst und immer die connection herumreichen musst...

Wie kann ich die Logik im Modell haben, wenn ich dort keine Methoden habe?
Ich glaube ich verstehe die "factory"-Klasse nicht.

Vom Ablauf her, wie soll das professionell denn dann aussehen?

1. . Oberfläche initialisiert Bean um z.B. einen User zu laden. Diese Bean entstammt der 1. Schicht (Ausführungsschicht)
2. . Bean instanziiert ein User-Objekt, welches sich mittels Konstruktor und userID automatisch mit weiteren Unterobjekten "behängt" und die Eigenschaften füllt.
   
   .....................
   und irgendwie wandern hier die Daten vom Datenbank-Connector-Objekt, in meinem Fall dbBackend, in die Modell-Objekte (Der User-Christbaum)
   ......................
   
3. . dbBackend bietet für jedes Modell-Objekt einen setter, getter, add und delete. Meist nur über die UserID die bei meinem Modell die grundlegenste Eigenschaft darstellt.

Wenn ich "Factory" richtig verstanden habe, schaffe ich damit eine Applikationsweit erreichbare Instanziierung von dbBackend, so daß ich es nicht herumreiche, oder?

 

[Bleiglanz]

im Prinzip hast du es schon erfasst

nicht user.savetoDb() implementieren, sonder dbBackend.save(user) schreiben

"irgendwie" heisst, dass in der Anwendungslogik ("Business Logic") mit den Modellobjekten gearbeitet wird (d.h. unter andrem, dass auf dias Backend zum Laden/Ändern/Speichern zugegriffen wird )

dazu musst du deine 2. Schicht aufteilen

2.A: Modell-Objekte (=Entitäten) unabhängig von allen anderen "Schichten"

2.B. Applikationslogik: Methoden, Verfahren, Algorithmen usw.; mit Zugriff auf das Backend und die Modelle