@Filter not working with Seam @Entity?

RobJellinghaus · **Joined:** Thu Jan 08, 2004 6:17 pm **Posts:** 278

I'm working with a tiny Seam application based on Seam 1.0.1's Hibernate example (e.g. using the JBoss microcontainer under Tomcat). I posted this question on the Seam forum and Gavin said to repost it here (the Seam posting is here).

I'm using the standard Seam test setup with an HSQL in-memory test database. All my configuration is essentially exactly like the Seam 1.0.1 Hibernate example.

I'm trying to declare a @Filter on one of my @Entities:

Code:

@Entity
@Name("blogPost")
@Filter(name="headOnly", condition="replicatedChangeset is null")
public class BlogPostImpl implements BlogPost, Serializable {
   private Long id;
...
   @Id @GeneratedValue
   public Long getId()
   {
      return id;
   }
...
   private Changeset replicatedChangeset;

   /**
    * The changeset in which this object was created.  Null for head objects; set for all
    * versioned copies.
    */
   @ManyToOne
   public Changeset getReplicatedChangeset ()
   {
      return replicatedChangeset;
   }
...
}

And I'm trying to use it in a query like this (yes, this is basically trying to make a version-tracking blog-posting system):

Code:

      new Script() {
...
         private Session database;
         @Override
         protected void updateModelValues()
         {
            database = (Session) Component.getInstance("database", true);
            assert database != null;
         }

         @Override
         protected void invokeApplication()
         {
...
            database.enableFilter("headOnly");
            List<BlogPostImpl> headBlogPosts = database.createQuery("from BlogPostImpl").list();
...
         }

      }.run();

The exception I get is that the "headOnly" filter is not found:

Code:

   [testng] FAILED: com.robjsoftware.replog.test.ChangesetTest.testChangeset()
   [testng] org.hibernate.HibernateException: No such filter configured [headOnly]
   [testng]     at org.hibernate.impl.SessionFactoryImpl.getFilterDefinition(SessionFactoryImpl.java
:962)
   [testng]     at org.hibernate.impl.SessionImpl.enableFilter(SessionImpl.java:1025)
   [testng]     at com.robjsoftware.replog.test.ChangesetTest$4.invokeApplication(ChangesetTest.java
:127)

What am I missing? Is there any other magic I need to do to make @Filter work for a Seam @Entity? Are there any known examples of trying this? Should I even be expecting it to work? Should I try moving this to hibernate.cfg.xml (since I do *have* a hibernate.cfg.xml)?

The Hibernate startup debug spam mentions "Binding entity from annotated class: com.robjsoftware.replog.domain.BlogPostImpl" but doesn't mention any filter annotations. Should it? What else could I do to debug why it seems to be ignoring @Filter here?

Thanks very much -- I'm planning a bunch of aggressive weirdness with @Filters in this application, so it'll be a big bummer if Seam doesn't grok @Filter yet....

I could easily provide a modified Seam Hibernate example to demonstrate this bug, if it would be helpful. Emmanuel, please let me know?
Cheers,
Rob

alesj · **Posted:** Fri Jun 30, 2006 5:02 pm

You can always check how @Filter is applied in JPA environment - debug.
Is it used or not. :-)

RobJellinghaus · **Joined:** Thu Jan 08, 2004 6:17 pm **Posts:** 278

I dug on this more last night, traced into the debugger etc., and it turned out that you *have* to have a FilterDef along with your Filter. In other words, this worked:

Code:

@Entity
@Name("blogPost")
@FilterDef(name="headOnly")
@Filter(name="headOnly", condition="replicatedChangeset_id is null")
public class BlogPostImpl implements BlogPost, Serializable ... 

Leaving out the @FilterDef results in the "No such filter configured" error (which should be "No such FilterDef and Filter configured"). Leaving out the @Filter (but leaving the @FilterDef) results in the enableFilter call apparently working, but no actual filtering happens!

And also, note that I had to change it to "replicatedChangeset_id is null" -- just "replicatedChangeset is null" didn't work. The filter text seems to be just stuck on the end of the where clause -- it's a SQL fragment, not an HQL fragment. This is definitely unexpected and could be a maintenance problem. The more I look at the Filter implementation, the more I have a few questions:

1) Anyone out there really using Filters in production for something?

2) Is there *any* SQL parsing or rewriting done on the Filter condition?

3) Is it possible to have Filters that specify join conditions? On the face of it, it seems like not, unless you play careful games with using only databases that support subselects in WHERE clauses. I want to write a filter that is basically this:

Code:

@FilterDef(name="oldVersion", parameters=("key", "maxIndex")
@Filter(name="oldVersion", condition="replicatedChangesetIndex = (select max(replicatedChangesetIndex) from BlogPostImpl bp2 where bp2.key = key and bp2.replicatedChangesetIndex < :maxIndex)")

Note that part of the where clause is to the "key" field of the "this" object, not to a query parameter. Does this have a hope in hell of working? I guess I'll soon know.

4) What's next for Hibernate? Is there still much active development on extending fringe features like Filters? If I submit a JIRA patch, is it likely to get rolled into a 3.3 (or whatever the next planned version is)? What *is* the next planned Hibernate version?

Cheers!
Rob

emmanuel · **Posted:** Fri Jul 07, 2006 9:51 am

RobJellinghaus wrote:

(which should be "No such FilterDef and Filter configured").

Open a JIRA issue, I'll try to enhance the exception message

Quote:

And also, note that I had to change it to "replicatedChangeset_id is null" -- just "replicatedChangeset is null" didn't work. The filter text seems to be just stuck on the end of the where clause -- it's a SQL fragment, not an HQL fragment. This is definitely unexpected and could be a maintenance problem. The more I look at the Filter implementation, the more I have a few questions:

1) Anyone out there really using Filters in production for something?

2) Is there *any* SQL parsing or rewriting done on the Filter condition?

3) Is it possible to have Filters that specify join conditions? On the face of it, it seems like not, unless you play careful games with using only databases that support subselects in WHERE clauses. I want to write a filter that is basically this:

Code:

@FilterDef(name="oldVersion", parameters=("key", "maxIndex")
@Filter(name="oldVersion", condition="replicatedChangesetIndex = (select max(replicatedChangesetIndex) from BlogPostImpl bp2 where bp2.key = key and bp2.replicatedChangesetIndex < :maxIndex)")

Note that part of the where clause is to the "key" field of the "this" object, not to a query parameter. Does this have a hope in hell of working? I guess I'll soon know.

4) What's next for Hibernate? Is there still much active development on extending fringe features like Filters? If I submit a JIRA patch, is it likely to get rolled into a 3.3 (or whatever the next planned version is)? What *is* the next planned Hibernate version?

Cheers!
Rob

Filter is based on SQL since you usually want to filter on some data not mapped to the Object. I makes filter a much more powerful feature

1. sure, filter is heavily used for temporal / versioned schema
2. yes, basically we prepend the table name on unqualified columns
3. filters apply on the where clause, so subselect is needed in this case
4. yes Hibernate is in active development, but you didn't even mentioned what you want to improve in filters ;-)

RobJellinghaus · **Joined:** Thu Jan 08, 2004 6:17 pm **Posts:** 278

Thanks Emmanuel, I did get it working. I'll try to get around to filing that JIRA issue soon.

It looks like maybe filters don't need as much improving as I thought :-)
Cheers!
Rob

mtbc · **Posted:** Wed Jul 13, 2016 9:07 am

Quote:

yes, basically we prepend the table name on unqualified columns

Aha, thank you: this explains a lot. I was having a problem with Hibernate mangling a table name after the FROM in a subselect in my filter condition: the table was named the same as a column in the join beforehand. In our case we are using PostgreSQL and suffixing the table name with an asterisk appears to be preventing the undesired mangling. I mention it here in case that workaround helps anybody else who found this thread in searching for people reporting that same problem.

Cheers,
Mark