EntityQuery with restrictions problem

[trouby]

Hey,
Sometimes restrictions cannot be based on EL expressions,

I have a class that inherits EntityQuery for an entity that has a property named 'End'

I would like to add a restriction that corresponds to a selectbox in JSF that has three string options ALL,FINISHED AND ACTIVE where:
ALL - any entry without restrictions
FINISHED - where End is not null
ACTIVE - where End is null.

so the restriction can look like

myEntity.end is not null

The problem is that I have to generate the value of the restriction based on the selected option,

setRestrictionExpressionStrings expects only expressions, not static strings.

I would like to check the returned value and add a static (string) restriction without any expression,

I tried to override getResultList and add it to the restrictions but it resulted many new exceptions

I couldn't find the right place to do that, is there any?

Thanks,

Asaf.

[trouby]

Anyone have any idea?

Many thanks,

Asaf.

[tamerg]

Any solution for this?
thanks.

[oguzyalcin.oguzhanyalcin.gazi.edu.tr]

Hi,
you can add this in your xxxList.java file. you have private static final String[] RESTRICTIONS variable in your file. Basically add your restriction at the end of the array. everything should work fine

[tamerg]

unfortunately RESTRICTIONS does not accept restriction like this

myEntity.end is not null 

it requires a value binding this really annoying.

thanks anyway.

[trouby]

Correct, that won't work,
What you can do is override getEjbql(),

As it's invoked on a very late phase,

Asaf.

[tamerg]

yes but with overriding getEjbql() dirty parameter checking not works and I also don't want to do this :)

[trouby]

Well,

This method is invoked after properties are bounded by the JSF update phase,
So you can add restrictions based on conditions,

And yeah, I don't like overriding this method either, it's a little bit dirty but this is the best option I found so far,

In old versions, it was possible to override getRestrictions(), but it doesn't work anymore,

Asaf.

[grundor]

I have similar problem where using RESTRICTIONS is not possible - in my case because I need to support OR logic.  So single value binding for me causes a problem.

If I understand this correctly, the suggestion is to override getEjbql() and build the query statement string myself?  If that is the case does this mean that every resultList call will be considered dirty?

It would be nice to still be able to use RESTRICTIONS for most of my query and then tack on any additional logic to handle non-single bindings.  But this doesn't look doable.

Asaf is it possible to post a little code sample of your getEjbql() override?

-Mark

[trouby]

Mark,

Yeah, from Seam 2.x it seems like you must set the restrictions when the object is being constructed,
Overriding getEjbql method works,

Here's an example:

@Override
public String getEjbql() {
  if (any logic can go here including variable of the extended EntityQuery that were set during JSF update phase) {
    //add some a restriction here...!
  }
}

Hmm if I remember correctly Query class iterate over all the restrictions and use AND between them while constructing the real QUERY, so I don't know how you can set OR conditions instead of AND,

Hope that helps,
Asaf.

[grundor]

Yes, that's right - the current implementation of Query class does not support restrictions like:

"((x.y = #{ref.foo}) or (x.y = #{ref.bar}))"

I found that someone had created a patched version of Query that handles multiple value expressions per restriction.  I have been trying to work with that code.

Here is the link to the JIRA:
JBSEAM-1065

From what I can tell this patch is going to work for me.

-Mark

[serkan.s.eskici.online.nl]

I had the same problem and I have solved it by placing the 'static' restriction in the WHERE clausule of the ejbql, thus something like this:

'
Select e from Entity e where e.prop = "string"
'

This works in Seam 2.2.1.cr2.

[antibrumm.mfrey0.bluewin.ch]

The restrictions in EntityHome need one and exactly one EL expression. If this EL evaluates to NULL the restriction will be ignored.

In your case i would say you can get around your problem with adding a restriction which does always evaluate to something but has no effect on the query itself.

Something like this:

(myEntity.end is not null and 1 = #{get1})

where 'get1' evaluates to 1 which could be a factory on the application scope