Wo ist der Unterschied bei diesem Select?

[Guest]

Hallo,

kann mir jemand verraten wo bei diesem Select der Unterschied ist?

Folgendes funktioniert:

Query lSelect = mSession.createQuery("FROM TextData WHERE text_id = 0");

Folgendes nicht:

Query lSelect = mSession.createQuery("FROM TextData t WHERE t.text_id = 0");

Fehlermeldung bei unterem:

Exception in thread "main" org.hibernate.QueryException: could not resolve property: text_id

Ich verstehs einfach nicht ...

 

[SlaterB]

vielleicht
SELECT t FROM TextData t WHERE t.text_id = 0

 

[maki]

Vielleicht so:

FROM TextData as t WHERE t.text_id = 0

Nachtrag: Bist du sicher das es eine Property namens "text_id" gibt? Würde mich doch sehr wundern...

 

[Guest]

beide vorschläge brachten die selbe Fehlermeldung.

habe in der Klasse Textdata zum testen die Property umgestellt auf

	private Integer TextId;

zugriff auf die property im HQL String sah dann so aus:

WHERE t.TextId = 0

=> Selbe Fehlermeldung. Habe im HQL String auch versucht den Spaltennamen in der tabelle anzugeben, verschiedene groß und kleinschreibung ... immer die slebe meldung!

 

[maki]

Nutzt Anno's oder Mapping files?

Was steht denn dort?

Abgesehen davon ist die Namenskonvention falsch, kann ja gar nicht gehen, Attribute IMMER KLEIN SCHREIBEN!
Wie sollte Hibernate denn das Attribut finden???

 

[Guest]

Nutze Annotations

@Column(name = "TEXT_ID")
	public Integer getTextId()
    {
    	return textid;
    }

Mal abgesehen davon das klein geschriebene Attribute eigtl. nicht mit der Firmen Internen Konvention zusammenpasst, klappts auch nicht wenns klein geschrieben ist :-(

 

[maki]

Mal abgesehen davon das klein geschriebene Attribute eigtl. nicht mit der Firmen Internen Konvention zusammenpasst,

Die Firmeninterne Konventionen sind falsch und führen zu Problemen in Java. Kannst du die Java Konventionen ändern? Ansonsten muss sich die Firma anpassen

So muss ein richtiges POJO aufgebaut sein:

..
    private Integer textId;
..
    public Integer getTextId() {
    ..
    }
..
    public void setTextId(Integer textId) {
    ..
    }
...

aber:
getTextid()
gettextid()

etc sind allesamt falsch!

 

[Guest]

Nur damit du mich nicht falsch verstehst, bei uns fängt kein Attribut mit einem Großbuchstaben an, von daher gibts auch keine Probleme mit Java, however: mein Code sieht jetzt genau so aus wie dein "richtiges POJO" und es geht nicht :-/

 

[maki]

Das liegt wohl an dir


FROM TextData as t WHERE t.textId = 0

 

[Guest]

bei der einen zeile isses nur leider nich möglich sich zu verschreiben und sogar dem copy & paste bin ich mächtig ^^

 

[maki]

Zeig uns doch mal:
- den gesamten Code der Bean
- den Stacktrace der Fehlermeldung

Nebenbei, deine Suche in der DB nach einem Transienten Objekt (id = 0) kann gar nix liefern.

 

[Guest]

Nebenbei, deine Suche in der DB nach einem Transienten Objekt (id = 0) kann gar nix liefern.

Ähhh doch, in der DB befindet sich ja der Datensatz mit der Id 0 ... Code wird gleich geliefert ...

 

[maki]

Ähhh doch, in der DB befindet sich ja der Datensatz mit der Id 0 ... Code wird gleich geliefert ...

Das bezweifle ich sehr stark, zumindest wäre dann etwas sehr faul
Abgesehen davon ist der Datensätz doch nicht von Hibernate angelegt worden, oder?

 

[Gast]

doch, war der erste datensatz den ich gespeichert hatte ...

 

[maki]

Dann ist etwas sehr faul.

0 ist nix.

Wie ist denn deine ID definiert?
Abgesehen davon kenne ich keine DB welche eine ID (PK) auf 0 setzen kann.

 

[Guest]

@GeneratedValue(strategy = GenerationType.AUTO)

Bei HSQLDB z.B passiert das schonmal [/quote]

 

[anderer Gast]

Anmerkung diese Entity funktioniert nicht, z.B. keine Id.

@Entity
public class Test
{

@Column(name = "TEXT_ID")
private int _testID;


public int getTestID()
{
return _testID;
}

public void setTestID( int testID )
{
_testID = testID;
}

public static void bla() {
Session mSession= null;
Query lSelect = mSession.createQuery("select t from Test t WHERE t._testID = 0");
}
}

Also wenn ich das richtig sehe Annotiert ihr eure getMethoden. Eine andere Moeglichkeit ist die Attribute selbst zu annotieren, damit sollte es dann auch keine Probleme mit irgendwelchen nicht "komforn" benannten gettern und settern geben. Kann ich dir aber nicht garantieren, da wir hibernate hier etwas anders einsetzen... Muesstest du also einfach mal ausprobieren.

Der Vorteil an der attribute Notation ist, dass du dann in der Querry den Attributnamen angeben kannst...

Also probiere doch bitte mal folgende Query mit Attribut Annotation aus:

SELECT t FROM TextData t WHERE t.text_id = 0

 

[Guest]

@anderer Gast
:toll: Getter und Setter sind "Wegwerfcode" und können jederzeit neu generiert werden, daher ist es
immer besser die Annotationen bei den Attributen zu schreiben.

 

[ms]

Wie wärs wenn ihr nicht den DB-Spaltennamen sondern den Attributnamen der Klasse im HQL angebt.

ms

 

[benders]

Hi!

1) textID hat doch nichts mit PK zu tun. Ist doch nur als @Column annotiert.

2)
Auch wenn Du name="TEXT_ID" angibst, musst Du in Deiner Query nach textid fragen.

3) Du schriebst:
@Column(name = "TEXT_ID")
public Integer getTextId()
{
return textid;
}

Die Variable heist also textid (alles klein) dann muss auch die Getter-Methode
getTextid() heissen.

Bernd