[Java/EJB] Date en EJB-QL

[zneek]

Ik heb hier een aantal EJb's. Hier zijn een finder methodes bij gedefinieerd. Bijvoorbeeld een findOpDatum(Date datum) met als EJB-QL statement:

code:

select distinct object (o) from Datum AS o where o.datum < ?1

Dus dit gaat over een Datum object met een datum attribuut. Dit is gedefinieerd als een java.util.Date. Nu krijgt de finder als attribuut mee een java.util.date.

Bij het deployen onder Jrun krijg ik de volgende foutmelding:
Invalid type for expression (o.datum < ?1)

Nu ben ik (al erg lang) aan het zoeken via Google en vind steeds tegenstrijdige berichten over het wel of niet kunnen gebruiken van een java.util.Date als parameter voor een EJB-QL query. Volgens diverse bronnen is het in de EJB2.0 spec niet mogelijk(zie theserverside of sun), maar andere sites geven vrolijk voorbeelden waar het wel kan (ejb-ql.com bijvoorbeeld).

Iemand hier ervaring mee? Kan ik een Date als parameter meesturen? Of moet ik (zoals de sun site zegt) alles naar long ombouwen? En moet ik dan ook het attribuut ombouwen van Date naar long?

[Verwijderd]

java.util.Date wordt niet native ondersteund door EJB-QL.
Oracle bijvoorbeeld heeft het wel toegevoegd, zoals ook een aantal anderen.

Zie bijvoorbeeld:
http://otn.oracle.com/tec...lateral/OC4J-FOV-904.html
en
http://www.theserverside....sp?l=MonsonHaefel-Column1

[ Voor 39% gewijzigd door Verwijderd op 19-09-2003 19:32 ]

[zneek]

Verwijderd schreef op 19 September 2003 @ 19:30:
java.util.Date wordt niet native ondersteund door EJB-QL.
Oracle bijvoorbeeld heeft het wel toegevoegd, zoals ook een aantal anderen.

Zie bijvoorbeeld:
http://otn.oracle.com/tec...lateral/OC4J-FOV-904.html
en
http://www.theserverside....sp?l=MonsonHaefel-Column1

Daar was ik ook achter Mijn concrete vraag is "Hoe los ik het op?" Kun je gewoon geen EJB-QL queries op Date attributen schrijven? Wat is de normale manier om het op te lossen(Volgens de EJB2.0 specs)? Dat is namelijk iets wat ik niet kon vinden. Moet ik de desbetreffende attributen geheel ombouwen tot bijv long attributen? Of is er een manier om een Date parameter te bewerken (tot bijv een long) en um dan mee te geven aan een EJB-QL query (die um vervolgens gebruikt om te vergelijken tegen het Date attribuut van de EJB)

[Verwijderd]

In Resin gebruik ik dit iig regelmatig. Welke db server hangt erachter?

[Verwijderd]

Volgens je post was je er nog niet zeker van of het in de spec zat...

Als sun hier een advies over geeft, zou ik die niet in de wind slaan als je spec compliant wil blijven. Ik denk dat er niet veel andere oplossingen zijn.
Door dit soort dingen gebruik het niet en schrijf ik liever alles met mijn eigen DAOs, die ik genereer...

TiCe, het heeft niet met de db te maken, maar met je app server.

[ Voor 7% gewijzigd door Verwijderd op 19-09-2003 20:36 ]

[Verwijderd]

Oh inderdaad,

ik had even over het 'bij het deployen' heengelezen, anders had het wel een sql foutmelding kunnen zijn.

[zneek]

Verwijderd schreef op 19 September 2003 @ 20:35:
Volgens je post was je er nog niet zeker van of het in de spec zat...

Als sun hier een advies over geeft, zou ik die niet in de wind slaan als je spec compliant wil blijven. Ik denk dat er niet veel andere oplossingen zijn.
Door dit soort dingen gebruik het niet en schrijf ik liever alles met mijn eigen DAOs, die ik genereer...

TiCe, het heeft niet met de db te maken, maar met je app server.

Dat is het leuke aan het verhaal. De verschillende zaken die ik gevonden heb op de sun site stellen allemaal dat Date gebruiken niet kan, gebruik long. Alleen staat er dan niet bij op welke manier precies. Voor het attribuut in zijn geheel? Of alleen voor de query parameter.

[zneek]

kleine update.

Flink aan het lezen geweest. Ik heb in een boek over Enterprise Java Beans zitten lezen (zo'n boek met van die Sun stempels en logo's, ik heb hier nu niet liggen).

Daarin wordt gesteld dat volgens de EJB2.0 spec er geen db(!) ondersteuning is voor het Date type, en dat daarom in de EJB's met longs gewerkt wordt. Ze omcapselen dit in de voorbeelden netjes met een Calendar object in de ValueObjecten (waarbij de setters en getters van het VO de boel om/terug rekenen van/naar longs).

Hoewel er app servers zijn die wel het Date formaat ondersteunen (naar de sql laag toe) is het volgens de EJB2.0 specs dus niet mogelijk. Ombouwen dus [sarcasme]Ach ja, ik heb toch niks anders te doen.[/sarcasme]

[zneek]

Nog een update: (kweetniet of er nog iemand meeleest, maar goed voor de volledigheid)

De werking is nu als volgt: de EJB heeft een Long attribuut. Deze wordt omkapseld met een setter en getter die met een Date/Calendar werkt. Intern wordt dit doorvertaald naar de setLong methode.

De queries dienen nu met Long attributen geschreven te worden. Beetje workaround om de crappy EJB2.0 spec heen. Zelfs in EJB2.1 schijnt nog geen volledige Date support te zitten. Lijkt mij toch wel een belangrijke issue om te verwerken, maar goed.

MEt de Long attributen deployen alle EJB's nu correct om Jrun. Onder Jboss deden ze dat al met de Date attributen.

[Verwijderd]

ik lees nog mee
(ben zelfs héél geinteresseerd, begin normaal gezien volgende week m'n allereerste job als EJB developer, en ken er nog maar weinig-basis van...)
dus als je effe tijd hebt en kan uitleggen/tonen (code copy pasten is genoeg, java ken ik wel hoor ) hoe die long - date mapping in z'n werk gaat, of map je dat zelf naar een eigengekozen formaat (ddmmyyyy,hhmmss ofzo?)??

[edit]
/me had beter even de api erbij genomen voor java.util.date en deze methode gelezen: long getTime()

[ Voor 16% gewijzigd door Verwijderd op 22-09-2003 19:14 ]

[zneek]

Verwijderd schreef op 22 September 2003 @ 19:11:
[edit]
/me had beter even de api erbij genomen voor java.util.date en deze methode gelezen: long getTime()

Inderdaad

Voor Date: Date.getTime() voor Calendar: Calender.getTimeInMillies().

Moet je nog meer weten dan post je hier maar wat. Geen garanties dat ik antwoord weet hoor Ben zelf ook nog niet zo lang met EJB bezig. Is wel een prima omgeving verder (op dat datum dingetje na).

[ Voor 28% gewijzigd door zneek op 22-09-2003 23:56 ]