Java & MS SQL - mal ein Problem für einen Profi

[speedy]

Oder hab ich was an den Augen? *g*

Yep. ... stell dir vor das "IDENTITY" heißt woanders "AUTOINCREMENT" ... die (1,1) bedeutet einmal der Startwert und dann um wieviel in jeder Zeile hochgezählt werden soll. Interessanter Weise - wenn ich den Typ der Spalte abfrage, dann steht da als Typ nicht einfach "INT" drin sondern "INT IDENTITY".


MFG,
speedy

[speedy]

Versuch es noch mal in einfach zu erklären

Also - es gibt zwei Methoden - eine fügt alle Insert's in den Batch, die nächste danach alle Updates. Jetzt hab ich also einen Insert eingefügt und gedacht die Update-Methode macht nichts, weil die Flags ja eigentlich so gesetzt sind, daß die gar nicht auf die Idee kommen könnte auch noch nen Update einzufügen - denkste - die hat die ganze Zeit auch immer noch nen Update für die AutoIncrement-Spalte eingefügt - und da man ja eine AutoIncrement-Spalte nicht updaten darf, kam dann der Fehler.

Irgendwas muß ich also beim Setzen der Flags irgendwo geändert haben, daß die Update-Methode anspringt - weil es hatte ja ne Zeit lang funktioniert.


MFG,
speedy

[tracer]

Yep. ... stell dir vor das "IDENTITY" heißt woanders "AUTOINCREMENT" ... die (1,1) bedeutet einmal der Startwert und dann um wieviel in jeder Zeile hochgezählt werden soll. Interessanter Weise - wenn ich den Typ der Spalte abfrage, dann steht da als Typ nicht einfach "INT" drin sondern "INT IDENTITY".

Ah, OK.
Habe noch nie mit was anderem als Oracle und MySQL gearbeitet.
MS-SQL und Informix habe ich administriert, aber nie selber genutzt.

Also - es gibt zwei Methoden - eine fügt alle Insert's in den Batch, die nächste danach alle Updates. Jetzt hab ich also einen Insert eingefügt und gedacht die Update-Methode macht nichts, weil die Flags ja eigentlich so gesetzt sind, daß die gar nicht auf die Idee kommen könnte auch noch nen Update einzufügen - denkste - die hat die ganze Zeit auch immer noch nen Update für die AutoIncrement-Spalte eingefügt - und da man ja eine AutoIncrement-Spalte nicht updaten darf, kam dann der Fehler.

Das habe ich jetzt auch verstanden

[speedy]

Hi,

ich nutz den Thread hier mal einfach für eine weitere Frage.

Und zwar hatte ich letzten Freitag nen Vorstellungsgespräch und da wurde ich auch auf der technischen Seite ausgefragt - ist glaub auch ganz passabel gelaufen.

Die Leute auf der "anderen" Seite waren eher Java-mäßig angehaucht.

Jedenfalls - haben die da so nen Fall konstruiert und da kam nachher eine Lösung raus, wo ich nicht ganz sicher bin, ob ich jetzt an das Gleiche gedacht habe wie die - obwohl mir die Variante der Lösung auch bekannt vorkam, weil auch in einem Projekt verwendet, aber irgendwie "oversized" für das Problem.

Wir haben ne Klasse "Sachen" ... um die Sachen weiter zu unterteilen in Hemden, Hosen etc. wurden von der Klasse weitere Klassen abgeleitet ... und da dann unter der Klasse noch symbolisch nen "riesen" Baum mit weiteren Klassen gezeichnet.

Jetzt kam die Frage, wie könnte man das auch anders machen, ohne eben diese ganze Ableitungshierarchie nachher zu haben. (weil dieser Baum bedeutet ja auch ne Menge Wartungsaufwand)

Eine einfache Variante wäre, in der Klasse Sachen einfach nen Enum einzubauen, mit der man die einzelnen Sachen unterscheidet.

Eine andere Lösung wurde genannt - kann mich nur grad nicht mehr an das Schlagwort erinnern - von der Art her, daß man an die Klasse einfach Eigenschaften für die Sachen "andockt".

Tja - jetzt die Frage - gibt es da irgendwas unter Java, mit dem man sowas einfach erledigen kann ?

Ich kenne zwar auch schon so eine Art Plugin-Mechanismus, aber der kommt mir für so "paar Eigenschaften" eben zu extrem vor. Damit konnte man zu einer Baugruppe eigene Funktionen etc. anstöpseln. Man mußte ein bestimmtes Interface implementieren und dieses dann noch per XML der Baugruppe bekannt machen. Dann wurden dort mehrere Methoden implementiert, in denen man eben sein "Zeug" gemacht hat, aber auch Routinen zur Ablaufsteuerung und Aufrufssteuerung usw. Dieser Plugin-Mechanismus wurde deswegen gemacht, damit man sich als "anderes" Teilprojekt auch da an die Baugruppe hängen kann, ohne an den Source von dem Baugruppen-Teilprojekt zu müssen ... hat aber auch Resourcen-mäßig einige Probleme gemacht.

Aber nur um zu sagen, daß die Klasse Sachen jetzt eine Hose ist und auch noch ein Längenmaß etc. etc. benötigt etc. ... das kanns doch nicht sein ...


MFG,
speedy

[duke08]

Hi speedy,

das klingt ja eigenartig. Dass einer eine "sinnvolle" Vererbungshierarchie durch etwas "anderes" ersetzen will, mit dem Argument, dass der Baum einen Verwaltungsaufwand erzeugt, ist, naja, etwas komisch. Da gibts sicher den einen oder anderen Fall, wo das aus bestimmten Gründen Sinn machen mag, aber in der Realität gibt es m.E. keine sinnvolle Vererbungshierarchie, die komplexer und schwieriger zu pflegen (und zu erweitern) ist, als eine "zentrale" Enum-Lösung mit switch/case-Unterscheidung. Es hängt letztendlich von den konkreten Anforderungen an Flexibilität und Performance ab, die normalerweise im Gegensatz zueinander stehen.

Um pauschal gewisse Eigenschaften an bestimmte Klassen/Objekte anzudocken, gibt es natürlich viele Gründe und Lösungen, aber das steht zunächst mal nicht in Konkurrenz zu Vererbung als Grundlage der Objektorientierung. Eine ganz einfache Möglichkeit wäre z.B. das hier:

Code: Alles auswählen

class Sache {
    enum Type { Hemd, Hose }

    static void registerPropertyProvider(PropertyProvider p) { /* ... */ }

    public Object getProperty(String name) {
        // registrierte Provider der Reihe nach dem Property fragen
        // ...
    }

    Type getType() { /* ... */ }
}

interface PropertyProvider {
    Object getProperty(Sache sache, String name);
}

class PropertyProviderImpl implements PropertyProvider {
    public Object getProperty(Sache sache, String name) {
        if (sache.getType() == Sache.Type.Hose) {
            if (name.equals("länge")) return new Integer(4711);
        }
        return null;
    }
}

Ist aber in der Tat zumindest für das Beispiel totaler Overkill und widerspricht hier dem OO-Konzept. Das ist eher ein Beispiel wie man es *nicht* macht, zumindest nicht in Java, C# oder auch C++.

Gruß
Sascha

[speedy]

Dass einer eine "sinnvolle" Vererbungshierarchie

Nunja, genau haben die mir natürlich nicht alles erzählt, was da alles in den Klassen gemacht wird. Aber das war wohl so, daß die es selber seinerzeit mal total genial und sinnvoll fanden bei der Entwicklung, aber ein außenstehender damit wohl überhaupt nicht klar kommt - man halt das Know How der Erstentwicklung benötigt, um damit klar zu kommen.

Verwaltungsaufwand

Naja - wenn du da jetzt an der Klasse Sachen was änderst, dann mußt du es in allen anderen abgeleiteten Klassen eventuell auch nachziehen - und das kostet Zeit.

Eine ganz einfache Möglichkeit wäre z.B. das hier:

Yep, so in der Art hatte ich mir das auch gedacht.

Gut - aber dann weiß ich zumindestens, daß es da nichts spezielles gibt, was ich in meinem Java-Unwissen jetzt nicht kenne.


MFG,
speedy