|
|
MySQL Administrator GUI
 hansi, 16.05.2008 15:29:22
Suche ein tutorial für die MySQL Administrator gui.
(Ich meine kein tutorial zu mySQL,
sondern eine Anleitung zur Bedienung von "MySQL Administrator" insbesondere
den Querry Browser)
Über einen brauchbaren link freue ich mich.
grüsse hansi
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: MySQL Administrator GUI
hansi, 16.05.2008 18:33:22
Hallo Michael,
ich finde leider nicht mehr den link :-(, es war ein Forumseintrag in dem
behauptet wurde das MySQL Query Browser zusammengestellte querys als
Java Code exportiert werden kann.
Das wäre eine feine Sache, und das wollte ich nachgucken ob es möglich ist
- und wenn ja wie es funktioniert.
HeidiSQL kenne ich auch und habe es auch im Einsatz. Der ist simple,
aber durch den "MySQL Query Browser" steige ich nicht durch.
Wenn er nichts taugt dann will ich meine Zeit nicht damit verbraten.
Beim schreiben von den java -> sql abfragen, rauben mir die Hochkomma, doppelte Hochkommas + Leerzeichen die Zeit. Mit den Querys an sich habe ich kein
Problem ich stolper nur immer wieder über die Kommatas.
Ich habe mich auch schon an hibernate versucht. Das ist jedoch eine weile her.
Zu der zeit als ich es getestet habe hat es Fehlerhaften Java Code erzeugt.
(War zur der Zeit als es auf eine neue Version umgestellt wurde.)
Es war frustrierend, und hat keine Zeitersparniss gebracht.
Wahrscheinlich sind die Bugs jetzt ausgebügelt. Jedoch sind bei mir
jetzt so viele SQL querys von Hand geschrieben das ich nicht mehr umstellen will. Ein Tool mit dem die SQL querys zusammengestellt werden und
dann als Java Code exportiert werden können wäre genau das richtige
für mich.
Grüsse und danke für die links.
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: MySQL Administrator GUI
mj, 16.05.2008 19:00:33
> das MySQL Query Browser zusammengestellte querys als Java Code exportiert werden kann.
Das glaube ich bis zum Beweis des Gegenteils nicht ;-)
> Beim schreiben von den java -> sql abfragen, rauben mir die Hochkomma, doppelte Hochkommas + Leerzeichen die Zeit.
Benutzt du keine PreparedStatements? Da hast du diese Probleme eigentlich nicht.
Michael
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: MySQL Administrator GUI
hansi, 16.05.2008 20:43:46
Mach ich was falsch, geht es einfacher, hab ich was verpasst?
zB:
String sql = "INSERT INTO `profil` (`id`,`name`) VALUES ('"+profil.getId()+"','"+profil.getName()+"')";
Ich kenne keinen weg um das Beispiel zu vereinfachen.
Kommt das '"+profil.getId()+"' in einfache Hochkommas oder nicht?
Das hängt vom DB Attribut ab.
Jedes mal nachgucken. Und wenn es nicht stimmt wird keine
Fehlermeldung geworfen - es hat einfach kein "rowsEffect".
Das raubt mir die Zeit und Nerven.
Die letzten 1/4 Stunden hat es mich gekostet weil ich einen Tip-
fehler im update hatte. Da sah es so aus. '"+name+" '
->" '<- Das Leerzeichen war zu viel. Logisch das die Spalte 'name ' nicht
gefunden wird.
OK ich könnte über den Spaltenindex gehen - ich finde das jedoch
problematisch falls die Tabelle geändert werden muss, sollte sich
dabei sich eine Spalten verschieben ist das Chaos perfekt.
hansi
PS PreparedStatements verwende ich. Hilft aber bei solchen
Fehlern auch nicht weiter, oder liege ich da falsch?
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: MySQL Administrator GUI
mj, 16.05.2008 23:07:42
> Ich kenne keinen weg um das Beispiel zu vereinfachen.
Ich schon:
String sql = "INSERT INTO profil (id,name) VALUES (?,?)";
pstmt = con.prepareStatement(sql);
pstmt.setInt(1, profil.getId());
pstmt.setString(2, profil.getName());
pstmt.executeUpdate();
Keine Hochkommata, keine String-Verknüpfungen mit '+', keine SQL-Injection.
Michael
NB, der Vollständigkeit halber:
Die Hochkommata um 'profil', 'id', 'name', also Tabellen- und Feldbezeichner sind überflüssig; sie sind nur erforderlich, wenn der Bezeichner ein Leerzeichen enthält, z.B. 'personen id', was aber grundsätzlich eine schlechte Idee ist (dann lieber: personen_id).
> Kommt das '"+profil.getId()+"' in einfache Hochkommas oder nicht?
Wenn du kein PreparedStatement verwendest: Ja.
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: MySQL Administrator GUI
hansi, 17.05.2008 01:07:36
Hmmm, konntest Du nicht wissen, habe es ja nicht gezeigt.
Das ist die Methode mit der ich die Inserts mache, sie gehen immer über
das PreparedStatement.
Update und delete sehen ählich aus.
private PreparedStatement prepStmt;
private InitialContext ctx = null;
private Connection conn = null;
private String sql = null;
private ResultSet rs = null;
private DataSource ds = null;
private int iLastInsertKey;
private int rowsEffect;
/**
* @TODO return auf void setzen
* generated idkey steht in this.iLastInsertKey
* anzahl der veränderten Zeilen steht in this.rowsEffect
**/
public ResultSet insertNewRecord(String sql) throws SQLException, NamingException{
this.sql = sql;
LOG.debug(sql);
openConnection();
this.rowsEffect = prepStmt.executeUpdate(sql, prepStmt.RETURN_GENERATED_KEYS);
ResultSet newResultset = prepStmt.getGeneratedKeys();
if(newResultset.next()) this.iLastInsertKey = newResultset.getInt(1);
rs = prepStmt.getGeneratedKeys();
return rs;
}
/**@TODO "java:comp/env/jdbc/devdb" aus der webAppProp auslesen.**/
private void openConnection() throws NamingException, SQLException{
this.ctx = new InitialContext();
ds = (DataSource)ctx.lookup("java:comp/env/jdbc/devdb");
conn = ds.getConnection();
this.prepStmt = conn.prepareStatement(this.sql);
}
(Die connetion wird durch die Aufrufende Methode geschlossen.)
Eine SQL Injektion sollte nicht möglich sein da ich nicht das Statement
sondern das PreparedStatement verwende.
Ich bin davon ausgegangen das PreparedStatement die Values von
sich aus parst und escaped denn es auf ein SQL Statement trifft.
Das ist doch der Grund warum PreparedStatement und nicht Statement.
Kennst Du eine ToolKlasse die eine HashMap oder so
via instanceof abfragt und dann den in den enstprechenden pstmt.setER switcht.
und dann das fertig zusammengebaute PreparedStatement zurückgibt?
Das wäre schön dynamisch. Array, Vector oder Hashmap rein PreparedStatement zurück, und mit Bildern wird es lustig :)
Das schreiben von so einem tool, davor habe ich mich bis jetzt recht
erfolgreich gedrückt.
hansi
PS
Die Hochkommata um Tabellen- und Feldbezeichner hab ich aus HeidiSQL
abgeschaut. Das der einzige rund die Leerzeichen sind wusste ich nicht.
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: MySQL Administrator GUI
hansi, 17.05.2008 01:17:14
Oder noch besser ein currentObject das meine Daten aus den Faces hält
rein in das tool, voher noch update oder insert festlegen.
Und der fisch ist geputzt.
Das wäre schön.
hansi
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: MySQL Administrator GUI
mj, 17.05.2008 09:15:14
> Das ist die Methode mit der ich die Inserts mache, sie gehen immer über
das PreparedStatement.
Das sieht nur so aus ...
> Eine SQL Injektion sollte nicht möglich sein da ich nicht das Statement
sondern das PreparedStatement verwende.
Nein, das tust du nicht. executeUpdate(String sql) ist eine Methode aus Statement, die in PreparedStatement nicht überschrieben wird. Die Möglichkeit einer SQL-Injection vermeidest du also nur, wenn du PreparedStatement so verwendest, wie es gedacht ist: mit prepareStatement und den diversen set-Methoden.
> public ResultSet insertNewRecord(String sql) throws SQLException, NamingException{
>
> this.sql = sql;
> LOG.debug(sql);
> openConnection();
> this.rowsEffect = prepStmt.executeUpdate(sql, prepStmt.RETURN_GENERATED_KEYS);
> ResultSet newResultset = prepStmt.getGeneratedKeys();
> if(newResultset.next()) this.iLastInsertKey = newResultset.getInt(1);
> rs = prepStmt.getGeneratedKeys();
> return rs;
> }
Die Methode verstehe ich nicht: Du rufst zweimal getGeneratedKeys auf, wertest das einmal in der Methode aus und gibst das zweite ResultSet zurück? Wozu brauchst du hier zwei ResultSets, und wo wird 'newResultset' geschlossen?
Mein nächster Einwand ist eher philosophischer Natur: Die Klasse sollte alle datenbankspezifischen Angelegenheiten kapseln, also keine ResultSets, SQLExceptions, NamingExceptions usw. zurückgeben, sondern nur Ergebnisse. Die Methoden müssen damit also Abfrage-spezifischer werden, aber das müssen sie ohnehin, wenn du PreparedStatements effektiv verwenden möchtest.
Michael
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: MySQL Administrator GUI
hansi, 17.05.2008 23:35:03
Hallo Michael,
> Nein, das tust du nicht. executeUpdate ....
Sieht so aus als ob ich mich dem dem Datenbankverbindungen
beschäftigen muss.
> Die Methode verstehe ich nicht
Wundert mich nicht, weil es nicht richtig ist, wie ich es gemacht habe.
Vermutlich wollte ich das rowsEffect und den insertKey
Zu dem muss ich dir recht geben das newResultset bleibt offen.
Einfach blöd wie ich das gemacht habe.
> philosophischer Natur:
> Die Methoden müssen damit also Abfrage-spezifischer werden.
Damit der Kode nicht mehrmals geschrieben werden muss.
dachte ich mir, ich entwickle ein "DefaultConnertor".
Die Abfrage-spezifische Klasse überschreibt die Methoden im
DefaultConnertor in dem das zusammenbauen des PrepairStatements
stattfindet?
Was hälst du davon? Wie machst du das?
Du pastest doch nicht jedesmal Identische Zeilen für den
Auf.- und Abbau der Datenbankverbindung.
Grüsse hansi
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: MySQL Administrator GUI
mj, 19.05.2008 18:20:55
> Du pastest doch nicht jedesmal Identische Zeilen für den
> Auf.- und Abbau der Datenbankverbindung.
Solange man das mit handgestricktem SQL sauber machen will, sehe ich kaum eine andere Wahl. Typischerweise - mal davon abgesehen, dass ich in der Regel nicht Tomcats eingebauten Pool nutze und auch keine Bilder in Datenbanken schreibe ;-) - sieht das dann etwa so aus:
private Connection getConnection() throws SQLException, NamingException {
Context initContext = new InitialContext();
Context envContext = (Context)initContext.lookup("java:/comp/env");
DataSource ds = (DataSource)envContext.lookup("jdbc/imagedb");
return ds.getConnection();
}
private void cleanup(ResultSet rs, Statement stmt, Connection con) {
if (rs != null) {
try {
rs.close();
} catch (SQLException e) {
rs = null;
}
}
if (stmt != null) {
try {
stmt.close();
} catch (SQLException e) {
stmt = null;
}
}
if (con != null) {
try {
con.close();
} catch (SQLException e) {
con = null;
}
}
}
public int addEntry(String filename, InputStream in) {
int updated = 0;
String sql = "INSERT INTO imagetable (" +
"filename, imagedata) VALUES (?, ?)";
Connection con = null;
PreparedStatement pstmt = null;
ResultSet rs = null;
try {
con = getConnection();
pstmt = con.prepareStatement(sql);
pstmt.setString(1, filename);
pstmt.setBinaryStream(2, in, in.available());
updated = pstmt.executeUpdate();
rs = pstmt.getGeneratedKeys();
rs.next();
int key = rs.getInt(1);
} catch (NamingException ne) {
log.error("Unable to load database driver", ne);
} catch (SQLException sqle) {
log.error("Unable to add entry: " + pstmt, sqle);
} catch (IOException ioe) {
log.error("Unable to add entry", ioe);
} finally {
cleanup(rs, pstmt, con);
}
return updated;
}
Der Vorteil ist die Kapselung. Nach außen sichtbar sind nur Methoden vom Typ "gib mir Bild Nr.6", "leg dieses Bild ab", "gib mir alle Bilder von user xyz", usw. Wie das intern geschieht, ob über eine relationale Datenbank, eine Objektdatenbank, das Filesystem, xml-Dateien, ... ist dabei völlig unerheblich; das kann hinter den Kulissen jederzeit geändert werden, ohne dass die 'Anwendung' etwas davon mitbekommt.
Michael
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: MySQL Administrator GUI
hansi, 20.05.2008 13:35:26
Hi Michael,
nach langen hin und her - habe ich mich gestern entschlossen,
mich nochmals an hibanate zu versuchen. Da ich mich konsequent an MVC gehalten
habe sollte das DAO mit hibanate kein Hexenwerk sein.
Ich verwende MySQL Foreign Keys - das wird ein Knackpunkt sein.
Übrigens habe ich mich schlecht ausgedrückt - hibanate hat keien Fehler gemacht.
Es war das Eclipse jBoss hibanate PlugIn das nicht das gemacht hat, was es sollte.
Diesmal lass ich die Finger von dem PlugIn. Ich werde die hibernateXML Dateien
von Hand coden. Die Datenbank und die Beans stehen ja schon und BeanFeldnamen
heißen genau so wie die Attribute in der DB, was das ganze Unternehmen ver-
einfacht.
Ich beisse mich grade das Hibanate Tutorial durch.
> Tomcats eingebauten Pool nutze und auch keine Bilder in Datenbanken schreibe ...
Tomcats Pool verwende ich. Bilder sind immer noch auf der FileEbene :-P
Wenn ich die Krise mit hibanate bekomme, erlaube ich mir deinen Kode für meine
Bedürfnisse anzupassen.
> philosophischer Natur:
> Der Vorteil ist die Kapselung.
Ich hatte nicht gedacht das für jede DAO? Klasse getConnection() und cleanup()
vorschlägst.
Mein oben genannter Gedanke war getConnection() und cleanup() auf public zu setzen, und
die Klasse, die addEntry(String filename, InputStream in) aufruft, erweitert Deine
gepostete Klasse und übrschreibt die Methode
public int addEntry(String filename, InputStream in)
Das finale cleanup(rs, pstmt, con) darf natürlich nicht fehlen.
Das erfordert eine gewisse Disziplin weil getConnection() und cleanup() public
sind aber nur von Deiner geposteten Klasse verwendet werden sollte. Und nur in
der überschreibenden methode verwendet werden soll.
Sauber gekapselt ist es jedoch nicht mehr.
Der Vorteil wäre das getConnection() und cleanup() nicht via copy&paste
eingefügt werden muss.
Damit die Datenquelle auszutauschen ist musste noch eine weitere "Schicht" dazwischen liegen. So könnte "gib mir Bild Nr.6" unabhängig von der "Datenablegeart" realisiert werden.
Naja, ein Gedankenspiel - ich schau mal ob mit hibanate zurecht komme.
Grüsse hansi
PS Mit dem PrepairedStatement bin ich ja voll ins Fettnäpfchen getreten.
Was verwendest Du um auf Datenbanken zuzugreifen?
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: How To debug a PrepairedStatement
mj, 22.05.2008 11:48:53
Schau dir lieber http://log4jdbc.sourceforge.net/ an.
Michael
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: How To debug a PrepairedStatement
 Terminator, 22.05.2008 13:00:46
Also Admin als auch Query Proggi kann ich nur empfehle!
Vor allem Query Lesezeichen find ich cool.
Könnt mir ehrlich gesagt nimma vorstelle mit PhPAdmin das zu machen.
> debug
hmm - weiss jetzt net was ma debuggen müsste
bei mysql gibs log_slow_queries
> addEntry
naja net schlecht, aba auch net toll
für was fängst die exceptions denn eigentlich ab?
nur um "Unable to load database driver" der message hinzuzufüge!!!
und wenn dann solde man das weiter werfen
auf jedenfall musste bei so ner version den counter auch immer in business logic noch mal prüfen und rollback jedesmal explizt steuern
> Du pastest doch nicht jedesmal Identische Zeilen für den Auf.- und Abbau der Datenbankverbindung.
???
con.close, con.open
Was is da s problem
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: How To debug a PrepairedStatement
mj, 22.05.2008 15:10:19
>> debug
> hmm - weiss jetzt net was ma debuggen müsste
> bei mysql gibs log_slow_queries
Er möchte halt die tatsächlich erzeugten SQL-Statements noch mal sehen. Kann doch durchaus Sinn machen, wenn etwas nicht so läuft, wie man es sich vorgestellt hat. Da das zunächst nichts mit lange laufenden Abfragen zu tun hat, ist der Hinweis auf log_slow_queries hier weitgehend sinnfrei, auch wenn das Wissen darum natürlich nützlich sein kann, sofern man seine Anwendung profilieren möchte - und Zugriff auf die MySQL-Einstellungen hat.
> für was fängst die exceptions denn eigentlich ab?
Komische Frage. Wofür fängt man Exceptions?
> und wenn dann solde man das weiter werfen
Wozu die Anwendung mit Details der Implementation der Persistenzschicht belasten? Über den Rückgabewert erfährt die Anwendung, was sie wissen muss und es kann entsprechend reagiert werden. Alternativ könnte hier eine selbst erstellte Exception geworfen werden, aber eine SQL- oder NamingException an die Anwendung weiter zu reichen, macht aus meiner Sicht keinen Sinn.
Michael
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: How To debug a PrepairedStatement
Terminator, 22.05.2008 15:28:17
> Er möchte halt die tatsächlich erzeugten SQL-Statements noch mal sehen
hmm - ok
irgendwie erschliesst sich mir da allerdings kein grund für.
ausser eben bei langen queries.
> Komische Frage. Wofür fängt man Exceptions?
eigentlich überhaupt nicht komisch.
Exceptions fängt man nur dann explizit ab, wenn man auch explizit darauf reagieren will.
Du hängst da aber blos nen string dran, der unnötig ist, alle infos einschliesslich wos geworfen ist, haste doch scha im trace
> Wozu die Anwendung mit Details der Implementation der Persistenzschicht belasten
ganz genau!
aber das is ja bei deinem Beispiel der Fall.
Muss man ja immer in der Anwendung bei jedem Statement Call noch mal return checken obs auch funktioniert hat und dann eben rollback auslösen
> Alternativ könnte hier eine selbst erstellte Exception geworfen werden
genau!
> aber eine SQL- oder NamingException an die Anwendung weiter zu reichen, macht aus meiner Sicht keinen Sinn.
Nicht an die Anwendung (Business Logik), sondern ganz nach aussen und dort Rollback.
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: How To debug a PrepairedStatement
mj, 22.05.2008 16:24:46
> Exceptions fängt man nur dann explizit ab, wenn man auch explizit darauf reagieren will.
> Du hängst da aber blos nen string dran, der unnötig ist, alle infos einschliesslich wos geworfen ist, haste doch scha im trace
Auf alle Exceptions, die im Rahmen dieser Datenbankabfrage geworfen werden können, gibt es keine sinnvollen Reaktionsmöglichkeiten, da die Datenbank in der Regel über die Anwendung nicht gesteuert werden kann. Die Anwendung wird aber häufig dennoch weiterlaufen sollen, weshalb die Exceptions eben einfach gefangen werden und der Fehlerfall nur geloggt wird. Da Logdateien nach meiner Erfahrung leichter les- und auswertbar sind, wenn jeder Eintrag mit einer kurzen Erläuterung beginnt, wird diese halt an den Anfang gestellt.
>> Wozu die Anwendung mit Details der Implementation der Persistenzschicht belasten
> ganz genau!
> aber das is ja bei deinem Beispiel der Fall.
Nein. Das Interface ist klar definiert: Ich übergebe Daten, die gespeichert werden sollen und erhalte einen Rückgabewert, der anzeigt, ob die Transaktion erfolgreich war, oder nicht.
> Muss man ja immer in der Anwendung bei jedem Statement Call noch mal return checken
> obs auch funktioniert hat und dann eben rollback auslösen
Das Rollback würde typischerweise schon im DAB erfolgen, die klassische MySQL-Anwendung kommt aber oft genug ohnehin ohne explizite Transaktionskontrolle aus, was bei so einfachen Statements wie hier ja auch nicht weiter tragisch ist.
>> Alternativ könnte hier eine selbst erstellte Exception geworfen werden
>genau!
Architektonisch ist eine neue Exception sicherlich besser, da hast du recht.
> Nicht an die Anwendung (Business Logik), sondern ganz nach aussen und dort Rollback.
Wo ist 'ganz außen'?
Michael
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: How To debug a PrepairedStatement
Terminator, 22.05.2008 17:46:56
> Wo ist 'ganz außen'?
bsw Filter
also mal n beispiel meinetwege ne DeadlockException oder was auch immer
YOUR CASE:
- addEntry schmeisst SQLException "DeadLock occured ..." in Method addEntry
- du fängst des nu extra ab (overhead), weil du zuätzlich "Unable to add entry" stehen haben willst
- dann gibste 0 an die Application zurück
- die Application checkt rückgabe wert
- die Application informiert, wen auch immer, dass rollback gemacht werden muss
- die Application bricht ab und leitet zu ne standard error page
OTHER CASE:
- addEntry schmeisst SQLException "DeadLock occured ..." in Method addEntry
- Is ne Aussnahme wird weitergereicht nach aussen, logik muss sich nicht kümmern drum
- aussen wird rollback durchgeführt und zur error seite geleitet
> was bei so einfachen Statements wie hier ja auch nicht weiter tragisch ist.
hä - das soll ne methode werden di innnerhalb von business logik aufgerufen wird
also auch mit anderen oder mehrfach
> klassische MySQL-Anwendung kommt aber oft genug ohnehin ohne explizite Transaktionskontrolle aus
na vielleicht bei ahnungslosen PHP Fuzzies:)
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: How To debug a PrepairedStatement
mj, 22.05.2008 18:24:50
> YOUR CASE:
> - du fängst des nu extra ab (overhead), weil du zuätzlich "Unable to add entry" stehen haben willst
Auch du kommst nicht umhin den Fehler zu fangen. Ich schreibe dazu einen Log-Eintrag, weil es mir das Leben einfacher macht. Du musst das nicht so machen.
> - die Application informiert, wen auch immer, dass rollback gemacht werden muss
Nein, das tut sie nicht, das wäre bereits Aufgabe des DAO.
> - die Application bricht ab und leitet zu ne standard error page
Das hängt von der Anwendung ab. Nicht alle sind so datenbankzentrisch, dass sie ohne Datenbankverbindung nutzlos sind. Bei anderen wird man vieles durch geeignetes Caching abfangen können (z.B. Read-Only-Anwendungen).
> OTHER CASE:
> - addEntry schmeisst SQLException "DeadLock occured ..." in Method addEntry
> - Is ne Aussnahme wird weitergereicht nach aussen, logik muss sich nicht kümmern drum
Das nennt man "error context expansion". Für gewöhnlich versucht man das zu vermeiden und Fehler stattdessen so nahe wie möglich an ihrer Quelle zu behandeln.
> - aussen wird rollback durchgeführt und zur error seite geleitet
S.o.
> na vielleicht bei ahnungslosen PHP Fuzzies:)
Dummerweise funktionieren sehr viele der Anwendungen dieser "Ahnungslosen" gut genug (wie z.B. dieses Forum ;-)). Natürlich wird man gerade im Java-Umfeld oft nicht ohne Transaktionskontrolle arbeiten wollen, aber oft genug kommt man halt auch ohne aus.
Michael
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: How To debug a PrepairedStatement
Terminator, 22.05.2008 18:48:45
> Auch du kommst nicht umhin den Fehler zu fangen. Ich schreibe dazu einen Log-Eintrag, weil es mir das Leben einfacher macht. Du musst das nicht so machen.
stimmt fangen und loggen muss natürlich gemacht werden
unterschied is wo und mit welchen auswirkung aufs logik proggen
> Nein, das tut sie nicht, das wäre bereits Aufgabe des DAO.
keine ahnung was du einsetzt oder wie du das meinst.
wenn n insert nicht funktioniert kannst auch net dei logik weiterlaufen lassen, weils dann beim drauffolgenden statement schon kracht oder inkonsistent wär.
> (z.B. Read-Only-Anwendungen)
hä?
readonly vs addentry
wir sprechen aber schon noch von der addEntry Methode oder!?
> Für gewöhnlich versucht man das zu vermeiden und Fehler stattdessen so nahe wie möglich an ihrer Quelle zu behandeln.
So na wie möglich nur, wenn man das explizit handhaben möchte.
> Dummerweise funktionieren sehr viele der Anwendungen dieser "Ahnungslosen" gut genug (wie z.B. dieses Forum ;-)).
Funktionieren != Richtig
Ab 2 executeUpdates brauchste auch ne Transaktion
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: How To debug a PrepairedStatement
mj, 23.05.2008 08:38:23
> wenn n insert nicht funktioniert kannst auch net dei logik weiterlaufen lassen,
> weils dann beim drauffolgenden statement schon kracht oder inkonsistent wär.
Schau dir noch mal die Beispiele an. Es sind einfache Beispiele mit atomaren Transaktionen. Ein Eintrag wird hinzugefügt und die Sache ist damit erledigt. Das Bild wurde in der Datenbank gespeichert, oder eben nicht. Keine weiteren Abhängigkeiten, kein davon abhängendes weiteres Statement, keine möglichen Inkonsistenzen.
> readonly vs addentry
> wir sprechen aber schon noch von der addEntry Methode oder!?
Ich bin allgemeiner geworden, weil du deine Methode der Weiterleitung auf eine Fehlerseite offenbar für die allein seeligmachende hältst. Eine solche Weiterleitung ist oft aber weder erforderlich, noch erwünscht. Je nachdem, wo der Fokus der Anwendung liegt kann eine simple Benachrichtigung, das etwas nicht funktioniert hat und man es später nochmal versuchen soll völlig ausreichen.
> Funktionieren != Richtig
Du solltest nicht die Augen vor der Tatsache verschließen, dass diese Anwendungen in der Regel sehr wohl richtig funktionieren.
> Ab 2 executeUpdates brauchste auch ne Transaktion
Das ist richtig, aber darum ging es in diesen Beispielen an keiner Stelle.
Michael
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: How To debug a PrepairedStatement
Terminator, 23.05.2008 09:05:02
> diese Anwendungen in der Regel sehr wohl richtig funktionieren
jo geb ich dir ja Recht.
Und wenns blos einfacher insert ist sowieso.
Mein bsw Forum is ja net grad ne grosse Geschichte.
Bei mehreren Statements läufts in der Regel auch richtig, aber kommts mal zu einem Fehler und es wird nicht mit Transaktion gearbeitet, haste halt einen inkonsistenten Datenstand.
Für mich n Worst-Case, weil wie willste das wieder richten.
> Das Bild wurde in der Datenbank gespeichert, oder eben nicht. Keine weiteren Abhängigkeiten, kein davon abhängendes weiteres Statement, keine möglichen Inkonsistenzen.
Hab mir dein Beispiel schon angeguckt ist ja nicht falsch.
Man will aber doch später diese CRUD-Methoden möglichst einfach innerhalb der eigentlichen Logik-Funktionen aufrufen.
Da finde ich es eben einfacher, wenn ich nicht noch mal den return auswerten muss, um eben falls nötig den Rollback zu starten.
Naja was solls.
Kann der OP selber entscheiden, hat nun genug Infos/Meinungen von uns bekomme.
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: How To debug a PrepairedStatement
hansi, 23.05.2008 16:00:57
Hi,
Ich hab mit großen Interesse eure Diskussion verfolgt.
Stand "meiner Dinge":
Das Projekt an dem ich Arbeite soll irgendwann produktiv sein.
Im Vordergrund steht das lernen.
Ich habe mir nach Michaels Muster Beispiel in die Datenbank alle
benötigten CRUDs geschrieben. Diesmal mit setern. Selbst in der WHERE
Klausel habe ich Platzhalter verwendet. Dies nur zu meinem Verständnis.
Verworfen habe ich den Gedanken es in meinem Projekt zu verwenden.
@Michael auch wenn ich Dein Beispiel nicht einsetze es hat
mir aufgezeigt was ich falsch gemacht habe. - Aus Fehler wird man bekanntlich
klug. Hier nochmal ein dickes Danke.
Warum will ich es nicht verwenden?
Bis jetzt habe ich 15 Tabellen in der DB. In denen es später Suchfunktionen geben soll,
die über Checkboxen gesteuert werden sollen. zB Sortierungsreihenfolge,
Spalten aus,- u. einblenden.
Dann kommt noch die Anzahl Variationen der verschieden Abfragenvariationen.
Ich denke es gibt bessere Wege so etwas zu realisieren.
Zu dem habe ich gelesen, das es nicht mehr Zeitgemäß ist, wie nach dem Beispiel von
Michael zu persistieren. In meinem Java Server Faces Buch wird Hibernate als aktuell
angewandte Technik genannt. Hierzu habe ich mich ein wenig eingelesen.
> ... mal davon abgesehen, dass ich in der Regel nicht Tomcats eingebauten Pool nutze
(Vermutlich ist das auch der Grund warum Michael nicht die in Tomcats eingebauten Pool
nutzt. Die Technik die zuständig ist Objekte zu Persistieren ist "zuständig" für
die Datenbank. So wie ich Hibernate verstanden habe muss das nicht so sein -
in meinen Augen macht das jedoch Sinn dies Hibernate zu überlassen. )
Ich hoffe das ich mich mit Hibernate auf dem "richtigen" Weg befinde.
Wenn nicht verbessert mich bitte.
Ich denke das Michaels Beispiel durchaus seine Berechtigung hat. In einem
"mini" Projekt in dem ein Technik wie Hibernate ein overhead darstellt der nicht im
Verhältniss zu dem Projekt steht.
> Also Admin als auch Query Proggi kann ich nur empfehlen!
Ich finde kein richtigen "Draht" zu dem - Ein Tutorial hab ich vergebens gesucht.
Transaktionen werde ich beachten müssen weil es N Redaktore gibt die auf
dem selben Datensatz arbeiten können. (Das ist für mich neuland das zu
erschließen ist.)
Grüsse hansi
> was bei so einfachen Statements wie hier ja auch nicht weiter tragisch ist.
Das Beispiel war (zumindest von mir) vorsätzlich simpel gehalten, es ging
Vordergründig um das "how to" Prepaired und
nicht um das SQL Statement an sich.
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: How To debug a PrepairedStatement
mj, 23.05.2008 16:42:50
> Zu dem habe ich gelesen, das es nicht mehr Zeitgemäß ist, wie nach dem Beispiel von
> Michael zu persistieren. In meinem Java Server Faces Buch wird Hibernate als aktuell
> angewandte Technik genannt.
Das ist richtig. Ein Projekt mit 15 Tabellen hört sich allerdings nach einem kleinen Projekt an. Zum Einarbeiten in Hibernate ok, ansonsten ist das für meinen Geschmack Overkill.
> Vermutlich ist das auch der Grund warum Michael nicht die in Tomcats eingebauten Pool
> nutzt.
Der Grund ist vordringlich, dass eine Anwendung damit gegen den Tomcat programmiert wird und nicht mehr ohne Anpassungen in einem Jetty, Resin usw. deployt werden kann.
> Transaktionen werde ich beachten müssen weil es N Redaktore gibt die auf
> dem selben Datensatz arbeiten können.
Das ist nur ein Aspekt. Der wichtigere ist - wie Terminator schon ausgeführt hat - dass zusammenhängende Operationen auch unbedingt zusammen ausgeführt oder im Fehlerfall auch beide verworfen werden müssen. Das klassische Beispiel ist die Banküberweisung: Geld geht von einem Konto ab und landet auf einem anderen. Kommt es zu einem Fehler, nachdem das Geld abgebucht wurde und kann so die Gutschrift nicht mehr vorgenommen werden, muss unbedingt dafür gesorgt werden, dass auch die Abbuchung nicht commited wird. Hibernate unterstützt dich aber auch dabei.
Michael
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: How To debug a PrepairedStatement
gandalf, 23.05.2008 18:22:55
> Zum Einarbeiten in Hibernate ok, ansonsten ist das für meinen Geschmack Overkill.
Sorry, wenn ich wiederspreche, wenn man die Einarbeitung mal hinter sich hat würde ich bei *jedem* Projekt, egal welche Größe, Hibernate gegenüber JDBC vorziehen!
> Der Grund ist vordringlich, dass eine Anwendung damit gegen den Tomcat
> programmiert wird und nicht mehr ohne Anpassungen in einem Jetty, Resin usw.
> deployt werden kann.
Wenn ich eine JNDI-DataSource nehme sollte das Vorhandensein und der Typ eines CP doch von der Programmierung unabhängig sein und sich auf ein paar wenige Zeilen Änderung in der Context-Def.-Datei beschränken.
gandalf
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: How To debug a PrepairedStatement
hansi, 23.05.2008 19:32:04
Wenn Hibernate ein Overkill ist, und das Beispiel nicht mehr mehr Zeitgemäß,
dann bleibt die Frage, welche Technik bei so einem Projekt angewandt wird.
Nach dem Einwand von gandalf ist Hibernate vorzuziehen.
Worauf ich hinaus will - Gibt es eine andere Technik,
die angemessener wäre? Ein Mittelmaß.
Der Vergleich bezieht sich ja ausschließlich, auf Hibernate gegenüber JDBC,
ohne das alternativen in Betracht gezogen worden sind.
Ich "kenne" nur die beiden Möglichkeiten,
aber es soll ja Dinge geben, von denen ich nichts weiß.
Grüsse hansi
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: How To debug a PrepairedStatement
mj, 23.05.2008 20:11:18
> Sorry, wenn ich wiederspreche, wenn man die Einarbeitung mal hinter sich hat würde ich bei *jedem* Projekt,
> egal welche Größe, Hibernate gegenüber JDBC vorziehen!
Die Geschmäcker sind offenbar verschieden, denn mir geht das ganz anders. SQL ist einfach, Hibernate komplex und allein die Konfigurations-Hölle geeignet, einem schlaflose Nächte zu bereiten. Aber mir ist bewusst, das viele das ganz anders sehen.
> Wenn ich eine JNDI-DataSource nehme sollte das Vorhandensein und der Typ eines CP doch von der Programmierung unabhängig sein
> und sich auf ein paar wenige Zeilen Änderung in der Context-Def.-Datei beschränken.
Sollte, tut es aber nicht, weil dazu zusätzliche Klassen erforderlich sind, die beim Tomcat 5.5 in common/lib (naming-factory-dbcp.jar), beim Tomcat 6 in lib (tomcat-dbcp.jar) stecken. Dahinter verbergen sich die Libraries commons-dbcp bzw. commons-pool aus dem Apache-Commons-Projekt.
> das Beispiel nicht mehr mehr Zeitgemäß
Für meinen Geschmack ist es zeitgemäß für kleinere Projekte.
> Worauf ich hinaus will - Gibt es eine andere Technik,
> die angemessener wäre? Ein Mittelmaß.
http://ibatis.apache.org/
Michael
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: How To debug a PrepairedStatement
hansi, 26.05.2008 19:47:03
Hehe, nette Geschichte das iBatis
Deutsche Docu, ein wenig Fehlerbehaftet. Ich will aber nicht
maulen, weil die Fehler sich auf die Grammatik beschränken und
der Syntaxfehler ist zu offensichtlich um aufzuhalten.
Zu dem hat mir die deutsche doku bestimmt 2-3 Stunden gespart.
(Deutsch liegt mir irgendwie besser.)
iBatis an sich deckt bis jetzt alles ab was ich benötige.
Besonders nett finde ich TypeHandlerCallback das ein
Mapping in eigene "Typen oder Klassen" ermöglicht.
zB DB Integer zu java String Yes/No.
(Wenn ich das auch aus der sicht von MVC
in den Controller legen würde.)
Was mich ein wenig Zeit gekostet hat war
<settings useStatementNamespaces="true" />
Habe ich entweder übersehen oder es steht nicht in der Doku.
Naja, wenn das in der sql-map-config-2.xlm steht,
klappt es auch mit der Namensauflösung.
Nach dem iBatis "frisch" bei den Apache aufgenommen wurde
denke ich das es auch zukunftsträchtig ist.
Zu dem halte ich viel von der Qualität der Apache Projekten.
Was mir bis jetzt noch nicht klar ist.
Wo liegt der Unterschied zwischen iBatis und Hibernate?
Es Mappen doch beide via xml, Java Objekte <-> DB
Ich denke auch, das viel von Hibernate abgeschaut wurde
Weil ein "Danke" an das Hibernate Team auf der Webseite
steht.
Die doku (tutorial) von Hibernate ist sehr umfangreich.
Erst im Kapitel 14 wird gezeigt wie Hibernate in einem
J2ee Projekt verwendet wird, dagegen kommt
iBatis schnell und effektiv zur "Sache"
Vermutlich es nicht so viel können wie Hibernate.
(Wobei anzumerken ist ich habe die Hibernate doku nicht
durchgearbeitet, sondern nur Oberflächlich gelesen habe.)
Sobald ich mein DB "gedöns" auf iBatis umgestellt habe,
kaue ich Spring durch. Das soll ja ganz gut zu iBatis
passen. Auch wenn, oder weil, ich keine Ahnung habe
was Spring ist.
Hibernate, kommt erst mal zu den Akten.
Michael solltest du das Forum mal verlassen - rufe ich
Staatstrauer aus. Dein Tipp war wieder ein Volltreffer :-)
Grüsse hansi
PS So ein gruseliger Lapsus mit dem PrepairedStatement
- Ich ärgere mich immer noch über mich. grrr
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: How To debug a PrepairedStatement
hansi, 26.05.2008 20:04:45
Ach ja - was ich auch "cool" finde.
So wie ich es verstanden habe, kann die
Datenbankverbindung kann ohne goßen Aufwand
vom pool auf direktes JDBC, via
xml/properties umgestellt werden.
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: How To debug a PrepairedStatement
hansi, 29.05.2008 21:25:13
@Michael
Ich habe den Eindruck das iBatis die Anwendung ausbremst.
Gemessen ist es nicht nur mein subjektiver Eindruck.
Hast du das selbe beobachtet?
Grüsse hansi
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: How To debug a PrepairedStatement
mj, 30.05.2008 08:33:45
Mit iBatis fügst du deiner Anwendung genau wie mit Hibernate eine weitere Schicht hinzu. Im Idealfall erzeugt Hibernate effizientere SQL-Abfragen als du es selbst tun würdest, und die Anwendung würde schneller. Ansonsten bremst die zusätzliche Schicht eine Anwendung natürlich ein wenig. Mir ist das noch nicht aufgefallen, aber im Zweifel hilft hier nur messen.
JMeter ist dein Freund.
Michael
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: How To debug a PrepairedStatement
hansi, 30.05.2008 13:37:49
Hi michael,
da ich nicht direkt über jdbc gehen will. Beibt iBatis erst mal im Einsatz.
Wenn irgendwas wirklich zu lange dauert werde ich nachmessen.
Ich war mir bewußt das ein neuer Layer die Applikation verlangsamt.
Das ist eben der Preis für Sicherheit und Vorteile bei der Entwicklung.
Es kann gut sein das ich nur ein wenig ungeduldig geworden bin,
bis ich das Ergebniss meines codes sehe. Klasss Kompilieren, bei Bedarf
Tomcat neustarten, jsp kompilieren - und dann endlich das Ergebnis.
Vielleicht sollte ich mir einfach einen neun schnelleren Rechner
für die Entwicklung kaufen.
Ich Dank Dir für das Messinstrumenten.
hansi
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: How To debug a PrepairedStatement
hansi, 16.06.2008 20:21:15
Hi nochmals,
ist es möglich einen ganz normalen select String mit ibatis abzusetzen.
in der Docu habe ich es übersehen oder es geht einfach nicht.
Sowas wie "select * from xy" -> an ibatis
(Das soll im Projekt eine vorübergehnde Sache sein. Nur komme ich nicht
weiter weil ich alles was mit jdbc dirkekt komuniziert rausgeschmissen habe.
Jetzt beist sich der Fuchs in den Schwanz und ich stecke mit der Umstellung
fest.)
Mir reicht eine Antwort wie "ist möglich" dann lese ich mir die Doku nochmals durch.
Grüsse hansi
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: How To debug a PrepairedStatement
hansi, 27.06.2008 12:08:48
Meine Begeisterung für iBatis hat ein wenig gelitten...
Resolution: Won't Fix
As the comments imply, this is not something we can fix... all of the rows are
required for an accurate group by. At best we may be able to throw an
exception upon attempting to use both together. We'll probably wait until v3
to add such an exception though. While I can't think of one, there is a slight
possibility of someone actually making effective use of this combination of
features...(?)
http://www.mail-archive.com/dev@ibatis.apache.org/msg02775.html
:-(
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Legende:  Anonymer User registrierter User sehr aktiver User
|
|
Hinweis: Auf dieser Seite liegen Links zu anderen Seiten im Internet. Für alle diese Links gilt: Wir
betonen ausdrücklich, daß wir keinerlei Einfluß auf die Gestaltung und die Inhalte der gelinkten Seiten
haben. Deshalb distanzieren wir uns hiermit ausdrücklich von allen Inhalten aller gelinkten Seiten auf
dieser Homepage und machen uns ihre Inhalte nicht zueigen. Diese Erklärung gilt für alle auf unserer
Homepage angebrachten Links
Redaktion/Betreiber von JSP-Develop übernehmen keinerlei Gewährleistung und Verantwortung für die Richtig-
und/oder Vollständigkeit von den auf den Webseiten JSP-Develop veröffentlichten Source Codes.
Die Verantwortung der Verwendung/Anwendung sowie etwaige Modifikation der hier veröffentlichten Sourcen
obliegt einzig dem Benutzer der Webseite, welche die veröffentlichten Sourcen in einer Applikation/Anwendung
einsetzt. Durch das Kopieren und/oder Benutzen der Sourcen in einer Applikation/Anwendung
bzw. etwaigen Abschriften wird dieser Rechtshinweis anerkannt.
Java, JSP, JavaServer Pages, J2EE, EJB, JDBC, JNDI, JTA, Sun, Sun Microsystems are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and in other countries.
IBM, WebSphere are trademarks or registered trademarks of International Business Machines Corporation.
Other trademarks and registered trademarks are the property of their respective owners.
|
|
|
|
