Discussions

News: Hibernate3 Filters

  1. Hibernate3 Filters (52 messages)

    Hibernate3 adds the ability to pre-define filter criteria and attach those filters at both a class and a collection level. Steve Ebersole discusses this filter capability, and how it can be powerful in your Hibernate applications.

    Read Hibernate 3 Filters

    Threaded Messages (52)

  2. not me[ Go to top ]

    Um, actually Steve Ebersole wrote this item...

    blog.hibernate.org is a group blog.
  3. not me[ Go to top ]

    Nitin, the article itself still lists Gavin as author, rather than Steve...

    Furthermore, it still claims that Gavin is "currently involved in the JDO expert group". I already pointed out last time that you should adapt that footer to current reality ;-)

    Juergen
  4. As a spring freak, I see a very usefull application here, using AOP and the spring hibernate abstraction: apply the filter in interceptor, after session opening but before business method invocation.

    This way you declaratively apply filters to your data, without awareness of the actual business code. You can have, for example, fine grained authorization policy enforced at data access level, with minimal overhead and effort (no programmatic check at object level).

    How does it apply to associations between objects ?

    Suppose that object A has a many-to-one relation with object B, and that object B is made invisible by a filter. Will A's B property be accessible / modifiable ? Now suppose that I modify A's fields (not relations with other objects) and that I commit change. Will the "null" value for the B property be taken into account? I think Hibernate's behavior should be strongly documented regarding these points.
  5. This way you declaratively apply filters to your data, without awareness of the actual business code. You can have, for example, fine grained authorization policy enforced at data access level, with minimal overhead and effort (no programmatic check at object level).
    Yup, you get it.

    And thats just the beginning.

    We have turned a whole class of problems that are currently handled by writing difficult (or at least tedious) queries into a declarative mechanism.
    How does it apply to associations between objects ?
    The filter applies to ALL data retrieved in the session, so it is enforced as you navigate the object graph.

    However, many-to-one's do not have filters, only many-valued associations do. There is no notion of a filter for single-point associations. (This makes incredibly perfect sense if you think about it in terms of the usecases.) We don't just go and suddenly null out single-ppoint associations, that would be evil. ;-)

    So yes, the data is fully modifiable, and all semantics of Hibernate are retained.
  6. There is no notion of a filter for single-point associations. (This makes incredibly perfect sense if you think about it in terms of the usecases.) We don't just go and suddenly null out single-ppoint associations, that would be evil. ;-)So yes, the data is fully modifiable, and all semantics of Hibernate are retained.
    How would you compare this with using interceptors to do the same thing? An interceptor on the collection accessor would be able to do the same kind of filtering I suppose, and it would also be able to block access to single-point associations.

    Also, if I understand you correctly this filtering is done so that it is specific to a particular user, i.e. different users cannot share the same object model. Isn't that kind of wasteful? What if tons of users want to access the same graph? Do you keep multiple copies?
  7. An interceptor on the collection accessor would be able to do the same kind of filtering I suppose, and it would also be able to block access to single-point associations.
    This filter is applied on the database.

    Read the article ;-)
    Also, if I understand you correctly this filtering is done so that it is specific to a particular user, i.e. different users cannot share the same object model. Isn't that kind of wasteful? What if tons of users want to access the same graph? Do you keep multiple copies?
    Um, Rickard, you need to learn about Hibernate's two-level cache architecture. Sharing data is not the same as sharing object instances. Indeed, sharing instances of transactional objects between many users is a Bad Thing, since it requires all kinds of synchronization and locking in the middle tier.
  8. Interesting combined with AOP approach[ Go to top ]

    In addition, of course, there is a lot of data which is NOT, by nature, shared between many users, must ESPECIALLY, the kind of data that you want to apply filters to.

    Remember, we are not thinking of CMS-type data that you are working with currently. Filters are not really so useful for that kind of system. We are thinking of more record-oriented systems in eg. insurance industry.

    Or maybe even reporting systems, where you cache the report, not the data.

    etc.
  9. In addition, of course, there is a lot of data which is NOT, by nature, shared between many users, must ESPECIALLY, the kind of data that you want to apply filters to.Remember, we are not thinking of CMS-type data that you are working with currently. Filters are not really so useful for that kind of system. We are thinking of more record-oriented systems in eg. insurance industry.Or maybe even reporting systems, where you cache the report, not the data.etc.
    Ok, I see, thanks for the clarification.

    I suppose the two-level cache stuff wouldn't be so useful in a CMS either. But isn't this exactly what JRoller does? Maybe I missed something (I often do).
  10. cache[ Go to top ]

    (1) I suspect that in a CMS it's better to cache fully rendered pages, rather than entity objects. (well, you cache both, I guess)
    (2) Most CMS systems are fundamentally non-transactional, so some of the concurrency issues are really not that difficult (furthermore, staleness off data is often no big deal).

    Still, we've seen people use Hibernate's second-level cache (and query cache) to implement some CMS-type systems with very high concurrency requirements. So it works. The only question is whether you really *need* something quite this sophisticated, or whether OSCache would do most of the job just as well ;-)
  11. cache[ Go to top ]

    (1) I suspect that in a CMS it's better to cache fully rendered pages, rather than entity objects. (well, you cache both, I guess)
    Well, there are all kinds of approaches here depending on your needs, but we always generate all pages dynamically, using a Java object model. There's way too many details that depend on the user, so caching rendered pages is very difficult.
    (2) Most CMS systems are fundamentally non-transactional, so some of the concurrency issues are really not that difficult (furthermore, staleness off data is often no big deal).Still, we've seen people use Hibernate's second-level cache (and query cache) to implement some CMS-type systems with very high concurrency requirements. So it works. The only question is whether you really *need* something quite this sophisticated, or whether OSCache would do most of the job just as well ;-)
    We do something in between, where the cache itself is used concurrently by all users, and, as above, we don't cache the generated HTML. The dynamic stuff is "fast enough" for most purposes.
  12. Ok, I see, thanks for the clarification.I suppose the two-level cache stuff wouldn't be so useful in a CMS either.
    It can be usefull for personalization, It saves memory or disk space (you do not cache the same data many times), content cache is more usefull for "news,products" (not user specific parts of page).
    Both are usefull if DB cache can not help and you can tolerate negatyve app cache aspects.
  13. Um, Rickard, you need to learn about Hibernate's two-level cache architecture.
    I suppose you are referring to the HDLCA. I tried finding info about how this works over at hibernate.org but found nothing. Got links?
  14. Cache doco[ Go to top ]

    http://www.hibernate.org/hib_docs/reference/en/html/performance.html

    I think we should add some more cache doco soon.
  15. use it in versioning (archive)[ Go to top ]

    Another example is in versioning of objects. I can have filter where I will have filter: "current_version == true". It is simple and I cannot use for old version of objects some extra archive tables.
  16. Oracle fine grained access control[ Go to top ]

    If I get this right, this looks a lot like the functionality Oracle provides with its Fine Grained Access Control feature (an example). Could the two be combined ? Perhaps implementing Hibernate Filters with FGAC on an Oracle database ?
  17. sorting-def ?[ Go to top ]

    It would be useful if Hibernate also supported the notion on sorting in the way it supports filtering by specifying filter-def.

    A use case for this is data being displayed in a UI table that allows users to do multi column sorting (in addition to filtering on multiple columns).
  18. Hibernate3 Filters[ Go to top ]

    I wish I could use this functionality now. I checked out the downloads and Hibernate site (roadmap ). Is 3 available in cvs, .... ? I've been using Hiberante (and evangelising) for a few years now, but have lost track of current/future dev. Sorry.
  19. Hibernate3[ Go to top ]

    Hi Mark, Hibernate3 is the name of the module in CVS.

    cheers!

    P.S. Hibernate3 road map is here:

    http://www.hibernate.org/About/RoadMap
  20. It amazes me the lengths the Java people go to to avoid having to dynamically create WHERE statements in their SQL. But I forgot that java programmers are not suppposed to have to know that 'foreign language' of SQL. But instead of doing the simple thing and just appending conditions to the SQL, they some up with convoluted and complicated (runtime bytecode manipulation anyone?) API.

    JDBC is so simple I can teach it to anyone within minutes:

    Statement st = con.createStatement();

    ResultSet rs = st.executeQuery("Select xxx from yyy where zzz");

    while(rs.next())
    {
      String xxx = rs.getString(1);
      // do somethiing with xxx
    }

    if(rs!=null) rs.close();
    if(st!=null) st.close();

    That is it. If you need more fine grained control then dynamically append conditions to the WHERE, or use the databases built in filtering mechanisms. No need to re-invent the wheel.

    But no, instead of that I am supposed to use some convoluted XML syntax for defining my stuff, and then I am forced to use some highly un-object oriented 'bean' objects to put data in, etc. Then I am supposed to use some non-standard bastardization of SQL (EJB-QL, HQL, JDO, etc.) that saves me from having to learn 'real' sql (sql being simpler and more useful than any of the above).

    I am amazed at how the java community loves to create all these convoluted un-object oriented (encapsulation anyone?) API's to avoid having to learn something about SQL, database triggers, procedures, etc.

    The thing that makes me mad is that, at some point, I have to go in and modify other people's code that uses all of this crap and it is a real nightmare.

    The Java community loves to create complexity when the simple solution is staring them in the face. You need to get back to basics folks.
  21. You forgot all the exception manipulation code. You forgot all the database connection opening and closing code. All this repetitive boilerplate code introduces more chances for bugs. So using a ORM framework saves you time in development, testing and maintenance, since you'll have less code to maintain. And ORM solutions offer you a safer path in case your system need to grow into caching, distribution, etc. Not mentioning that every change in database schema will affect your pure JDBC java classes, where in an ORM solution, your classes may be shielded against some database changes.

    Regards,
    Henrique Steckelberg
  22. I just get a connection from a DataSource (although this is usually hidden by a utility method). The connection is put into the request, and the various selects, inserts, updates, deletes, etc that run just get the connection from the request. The controller servlet (from which all of my servlets extend) takes care of getting and closing the connection. Additionally, the controller servlet takes care of any exceptions that are thrown and rolls back any trackactions, etc. so really there is very little more for each SQL item than what I showed above.

    As for database changes, if I change a column name from 'firstName' to 'first_name', you will have to change something in hibernate, am I wrong? Changing Java code is no harder than changing hibernate XML files.

    Besides, sheiding from database changes is a relatively weak argument for introducing the complexities of an ORM framework into the mix. That *IS* an argument for accessing database stuff entirely through stored procedures. Then you are sheilded, to an even greater extent, from database changes because all of the SQL is in the database. All you need to know are the stored procedure names and what params to pass. Additionally, your SQL will run faster because it does not need to go over the network for each update (say for doing mass updates), etc.

    I say again, the java community is largly facinated with creating as much complexity to avoid doing what are simple. Take, JSF for example...I have a static utility method to generate an input field...it is one line of code. Now look at all of the hoops you have to go through in JSF to make your own input field 'component'. You have to create like 5 files (tag file, validator file, implementation file, render file, xml mappings, etc.) BLAH!

    Lets just see how many layers of confusion and indirection we can make huh?
  23. The simple fact that you are coding in Java means that there is a layer of indirection in every program you make. If you really want to do things as barebone as possible, I suggest you code in C or Assembler. The fewer layers of indirection you can get.

    Of couse I am well over the top, the point is: there are some layers of indirection that can really improve your work, *IF* it is suitable to what you are doing. It is always a case of using the right tool for the right job, and this applies to everything you do. If Hibernate doesn't improve your work, and you feel JDBC code is more than up to the task (you're more used to it, you already have all your template code ready, etc.), then don't use it.

    Now if someday you need to plug caching, clustering and other complex solutions to your existing JDBC code, it will centainly be harder than if you hgad leveraged on an existing framework that already provides all that besides the basic.

    Besides, one day someone other than yourself will have to maintain your code, and even if it is well documented, frameworks have a greater chance of someone already know its APIs and all, so one may get full speed faster with someone else's code if it uses a framework.

    Regards,
    Henrique Steckelberg
  24. The comments about assembly are out of place...what I mean is JDBC is already simple enough that we don't need *more* layers on top of it, to do things that most apps don't need, anyway.

    By your arguments, we should all be doing EJB because we *might* need it *someday*. You can always play the 'what if' game and over-engineer your code, and make it more complex/hard to maintain, but I feel that coding as simply as possible (when it is sufficient) is a much better approach...don't do more than is required. Obviously, if your requirements are that such things that Hibernate provides are needed, then maybe it's useful and should be considered.

    I would make the argument that more people are familar with JDBC than Hibernate, or any of the myriad of other ORM frameworks out there...so one would probably be safer with JDBC from a maintenance standpoint, than Hibernate.
  25. Of course, if your application is using a rather "table oriented" approach, using JDBC and plain SQL is quite fine.

    However when using a real complex domain model, e.g. an object-oriented view of your buisness logic, an ORM can reduce the needed code a lot. Mapping SQL query results to objects is a tedious task, and a lot of features of an ORM - which you will need - like lazy association fetching, dirty checking, etc. are difficult to implement in a clean way and to maintain.

    So of course ORMs are not a silver bullet for all cases, but are extremely useful when using a real domain model.

    When I am developing, there is a natural progression of tools, depending on the level of complexity needed:

    - JDBC with utility classes like jakarta dbUtils - for simple, very table oriented applications
    - iBatis - where the SQL code is more dynamic, and simple object-mapping is required
    - Hibernate - when I have a complex object model, using inheritance, association, components, etc
  26. I don't understand what 'table oriented' means.

    Are you saying that calling getters and setters on some object (which is not object oriented...it completely violates encapsulation) is better than setting parameters on a PreparedStatement?

    I see this kind of stuff all the time...there is a query...then the results of the query are populated into a 'bean', then the beans values are put out onto the JSP. Needless data copying. Instead of just getting the data out of the ResultSet and using it directly where it is needed...java guys are facinated with copying the data multiple times before it gets to it's final destination.

    It seems that ORM frameworks push this idea heavily...that using a POJO is somehow better than dealing with ResultSets/Statements, etc. To me using POJO for persistentcy is more confusing because you can't tell by looking at the class how it is intended to be used...it does not implement any interfaces, etc. The code is less clear. That is, unless you want to wade through a big book on Hibernate, only to find out that it uses some complex runtime reflection (or bytecode manipulation...or something) to extract the values, etc. Far to much 'magic' to be clear and maintainable unless you are an expert on the ORM framework.

    On top of that, since so much is done at runtime (i.e. the save method takes Object, of all things) I can throw whatever garbage I want into the save method and it compiles beautifully...only to bomb horribly at runtime. No type safety.

    Anyway, I'm tired and going to bed. I'm just sick of all the java lemmings following the next big 'fad' in programming, even when there are simpler/better solutions available.
  27. One of the choices we have always made, is never to try and argue with people who have never used Hibernate, and convince them that it is the best solution to their problems. It's just pointless. (Indeed, ORM is *not* the best solution to for all application.) Instead, we have been successful because people have tried it out and had success in real projects.

    You've clearly never used Hibernate, and so it's unsurprising that you have no idea what the advantages are (and what the problems are).

    Try it.

    And if you havn't tried it, ask yourself whether you are really qualified to criticize people who *have* tried it for using something that works well for *them*.
  28. It is funny to see people going like: "if *I* don't need it, then no one should need it too!". It just shows a limited and selfish view of the world.
  29. Dear Michael.

    You reply is very interesting.
    Pls, call us back when you database grow to 200+ tables.
  30. You can't call me, but I've just spent a week working with Hibernate on a project with several hundred entities. It wasn't for the first time. But hey, I could have also spent the week writing CRUD SQL statements, instead of tuning the caching, fetching strategies and make use of the other optimizations I get with a full ORM tool. Or I could have written my own persistence tool, because I don't like stuff I haven't invented.

    I guess it depends on your personal horizon and your masochist factor.
  31. Or I could have written my own persistence tool, because I don't like stuff I haven't invented.
    A very important point indeed: Never invent your own O/R mapping tool in-house, except in case of very special requirements. There's a variety of tools to leverage and customize out there now, which is a great thing.

    The persistence tool landscape wasn't so rich a couple of years ago, when everybody built their own O/R mapping solutions. This might have been a valid strategy back then, but those old habits are no longer appropriate now.

    Juergen
  32. 200+ tables[ Go to top ]

    Dear Michael.You reply is very interesting.Pls, call us back when you database grow to 200+ tables.
    Funny, systems with hundreds of entities is EXACTLY the kind of system we target with Hibernate, and EXACTLY the kind of system where ORM is most appropriate.

    Indeed, that is exactly what we are seeing on customer projects, these are the kind of projects where handwritten JDBC simply isn't appropriate.

    (200 entities is not really a very complex database, by the way. That's just normal size for a brand new database on a medium-size project.)
  33. 200+ tables[ Go to top ]

    Dear Michael.You reply is very interesting.Pls, call us back when you database grow to 200+ tables.
    Funny, systems with hundreds of entities is EXACTLY the kind of system we target with Hibernate, and EXACTLY the kind of system where ORM is most appropriate.
    Gavin - I think this post was sticking up for Hibernate :-) It's easy to get lost in all this "my dad can beat up you're dad" BS. Hibernate is popular because it rocks - period. It filled a need that other ORM solutions didn't. Way to go and thanks. I've nothing but love for you.
  34. oops[ Go to top ]

    Dear Michael.You reply is very interesting.Pls, call us back when you database grow to 200+ tables.
    Funny, systems with hundreds of entities is EXACTLY the kind of system we target with Hibernate, and EXACTLY the kind of system where ORM is most appropriate.
    Gavin - I think this post was sticking up for Hibernate :-) It's easy to get lost in all this "my dad can beat up you're dad" BS. Hibernate is popular because it rocks - period. It filled a need that other ORM solutions didn't. Way to go and thanks. I've nothing but love for you.
    Heh, oops, there were two Michaels in the thread, I thought it was a reply aimed at Mr. Gloegl. Sorry Dmitriy!
  35. Heh, oops, there were two Michaels in the thread, I thought it was a reply aimed at Mr. Gloegl. Sorry Dmitriy!
    No probs, Gavin.
    Yep in releational model is different but Hibernate is O/R mapping tool which tries to map releational model to the object model is in it?
    I think, that Hibernate isn't going to fully shield you from database and yes, it ties to map objects to tables. However, mapping done by "relational" laws, not by "objects" laws. Bad news, you still should know what is RDBMS :))) Good news, you get DBMS perfomance.
  36. 200+ tables[ Go to top ]

    As I understand choise doe's not depend on table count. If you prefer model as complex object graph then you need to map it, but database is not necesary complex for complex domain, so I think modeling dictates this choise and it is not trivial to find the best way (tool can not solve the main problem).
  37. O/R Mapping tools are not exclusive to Java.

    It is not like any of us have not done it the JDBC way, or the ADO way or, ... or that we are not in some situations. But when I view the database as a way to persist my objects, then I try to persist (hydrate, dehydrate) my objects in an OO manner.
    On top of that, since so much is done at runtime (i.e. the save method takes Object, of all things) I can throw whatever garbage I want into the save method and it compiles beautifully...only to bomb horribly at runtime. No type safety.
    Oddly enough, being able to do things at development/compile time is why I try to use O/RM (if using a reletional db) as often as possible.
  38. When I am developing, there is a natural progression of tools, depending on the level of complexity needed:
    - JDBC with utility classes like jakarta dbUtils - for simple, very table oriented applications
    - iBatis - where the SQL code is more dynamic, and simple object-mapping is required
    - Hibernate - when I have a complex object model, using inheritance, association, components, etc
    JDBC is particularly appropriate for set-based operations, like mass updates or mass deletes, or data analysis and processing. This is where full O/R mapping solutions typically introduce significant (or even enormous) overhead. JDBC access libraries like Spring's JDBC support or Jakarta Commons DbUtils significantly help to reduce boilerplate code in JDBC operations, letting application code focus on the actual data access operations.

    iBATIS SQL Maps essentially externalizes SQL statements and parameter/result mappings. You still work at the SQL level, but in a more convenient fashion, and with externalized mappings. For full CRUD of a persistent object, you still need 4 statement definitions; but for cases where you don't need full CRUD for all your objects in the first place (for example, if many of them are read-only anyway), this doesn't matter too much.

    "Full" O/R mappers - like Hibernate, JDO and Apache OJB - are indeed appropriate for complex domain models that mostly consist of mutable objects. They avoid the need to code CRUD operations for all your domain objects, plus fetching and caching strategies etc. They typically also offer automatic change detection, to avoid explicit store calls on modified objects. Of course, those benefits incur a certain level of additional complexity.

    As a side note, Spring explicitly supports convenient JDBC access, iBATIS SQL Maps, Hibernate, JDO, and Apache OJB - all with a consistent data access and resource and transaction management model. It's also straightforward to mix a variety of data access strategies there: Most importantly, there's often a need to code some operations at the JDBC level (for example, BLOB access), even if an application heavily relies on full O/R mapping in other places.

    Juergen
  39. Hibernate3 Filters[ Go to top ]

    Hi Hibernate folks,
    I hate repeating myself, but I believe with these new fancy (and very useful) features you are forgetting very important one: 1-m unidirectional associations.
    Current version (2.1.x )forces to use bi-directional 1-m associations (asume that I can't change data model). As I know folks from OJB already have feature called (anonymous foreign keys). Do you have this feature planned for 3.x?

    Regards,

    Giedrius
  40. Hibernate3 Filters[ Go to top ]

    This obviously wrong view pops up from time to time. We have an explanation in the FAQ, the book, and many postings on the forum. I guess we should add a big NOTE to the reference documentation:

    THERE IS NO PROBLEM WITH UNIDIRECTIONAL ONE-TO-MANY IN HIBERNATE!

    If A and B have a one to many relationship, and you want to have it unidirectional only from A to B, then the foreign key in the table of B has to be nullable. Everything else would be very very wrong and would encourage people to have invalid object and data models. We don't do that. If you still insist (don't I remember your name, you keep postings this everywhere you can?) that there is a problem that needs to be solved, solve this first: If you save a B (without any reference to an A), what should be inserted into the FK column?
  41. Hibernate3 Filters[ Go to top ]

    You sound nervous and hysteric, take it easy :) I just posted my opinion and you started to scream, roflmao :). You remind me Cocobase fame Ward Mullins :).

    I do know that by making key nullable it will work. But nullable key means that child life-time does not depend on parent life time. Now imagine (if you can) that I want to have 1-m association in which child can't not exist without parent. Is it wrong object model? Is it wrong data model?

    I just posted my opinion that this kind of feature should be included in any good O/R mapping tool. Yep I posted couple of times about this. And you know why I did that because I love Hibertante :).
  42. Hibernate3 Filters[ Go to top ]

    <quote>
    If you still insist (don't I remember your name, you keep postings this everywhere you can?) that there is a problem that needs to be solved, solve this first: If you save a B (without any reference to an A), what should be inserted into the FK column?
    </quote>

    Listen Gringo it why OJB guys have anonymous Fk feature :)
  43. Hibernate3 Filters[ Go to top ]

    Listen Gringo it why OJB guys have anonymous Fk feature :)
    Great feature, it is what every full ORM does and I wouldn't write pages about, because it is implied and expected. There is nothing about your particular problem in "anonymous FKs".

    Did you find an answer to my question? You see any other way than throwing a FK violation exception if you save a B without a reference to A? Apparently you don't like that part and expect an ORM tool to do some magic. You are welcome to bring this discussion up on the Hibernate forum if you need more explanation.
  44. blah blah[ Go to top ]

    I understand that you *really* need to think this one through to understand it, and its one I've never quite been able to explain in text. First of all, you need to understand that Hibernate is very different to some other solutions in that it supports detached operation (your jibe about OJB "anonymous keys" is silly).

    Imagine a detached Child, that I reattach. It doesn't know about the parent. Now imagine I reattach its old Parent, after I remove it from that detached parent's collection.

    How does the ORM solution figure out what the parent is? Search all the other objects in the persistence context to figure out if one of them has a reference to the child *every time we dirty check the session*? Potentially very inefficient. Especially if you recall that a Child might have multiple "parents".

    You also need to be generating the SQL UPDATE statements dynamically, since you must accept that the case of "unknown parent" is the common one. (I don't think this is such a big deal, but its ugly.)

    The problem here is that the detach-then-reattach process loses information about the entity in question. Thats not good.

    Now, In light of these problems, I've considered providing this feature only for the case where the parent reference is immutable (probably the common case), which avoids the need for all that dirty checking (and also avoids the need to dynamically generate SQL UPDATE statements when the parent reference is not known).

    *But*....

    ...and heres why I never got round to implementing this:

    Your object model is insane.

    You have declared, in your relational schema that: Child is completely dependant upon Parent. It can't exist without it. The Parent is a fundamental part of the definition of the Child, and a fundamental part of the data contained "in" a Child.

    And yet, in your object model, you've decided that it will be impossible to navigate from the Child to the Parent; impossible to even discover, given the Child, what its Parent is. This is just silly. I guarantee you, that whenever you write a persistent domain model like this, you will later on come along and change it to add a backreference to the parent. Every Single Time.

    Why? Because the nature of relational data is that it supports *ad hoc* querying. It is *not* a navigational data model. The notion that every time I want to get to a specific Child that I have to go through via its Parent is simply wrong in the relational world. I *all the time* want to query for particular children, and then navigate back to their Parents. If I can't do that efficiently (eg if I have to load up ALL children of a parent, just to get the particular child and parent together), the system simply won't perform.

    So, you think you want this, but you don't.
  45. blah blah[ Go to top ]

    So, I guess, my answer is: I could implement this but

    (1) it would probably be a performance bug in some circumstances
    (2) if I implemented it, people would probably try to use it, which would be a bad thing

    So I don't want to.
  46. blah blah[ Go to top ]

    If I understand it right, there really are 2 solutions to this: either you set your FK as nullable in your relational model, or you make the relationship navigable both ways in your object model. I would obviously prefer the second option, since integrity constraints shouldn't be changed in a database just because you have limitations in the application that uses it.

    Regards,
    Henrique Steckelberg.
  47. blah blah[ Go to top ]

    Gavin,

    My object model is insance because I do not want dependencies between packages?


    I guarantee you, that whenever you write a persistent domain model like this, you will later on come along and change it to add a backreference to the parent. Every Single Time.

    I don't think so because imagine I have class Order and then variuos OrderItems for variuos products. And these different implementation of OrderItem are in different packages. Now what is the reason for me to keep back reference to Order in items and mantain bi-asscoation? There is no reason it introduces just additional dependency in the model.


    The notion that every time I want to get to a specific Child that I have to go through via its Parent is simply wrong in the relational world. I *all the time* want to query for particular children, and then navigate back to their Parents. If I can't do that efficiently (eg if I have to load up ALL children of a parent, just to get the particular child and parent together), the system simply won't perform.


    Yep in releational model is different but Hibernate is O/R mapping tool which tries to map releational model to the object model is in it?

    Ok enough I do not give a shit if you will implement this functionality or not but you just lost Hibernate user. I just surprised how ignorant you and Chritian became. Before Hibernate wasn't so popular you were friendly dudes from an Hibernate project.

    Piece,

    Giedrius
  48. blah blah[ Go to top ]

    Yeah, whatever. Goodbye TSS. Get a moderation system.
  49. ?[ Go to top ]

    Um. I just wasted half an hour typing up what I assumed was a thoughtful and helpful reply to your questions.

    I won't bother again.
  50. Hibernate3 Filters[ Go to top ]

    solve this first: If you save a B (without any reference to an A), what should be inserted into the FK column?
    Nothing should be inserted in the database, instead a foreign key exception should be thrown, since every B should have a reference to an A. This is called an integrity constraint, and should be supported someway by every serious database and ORM framework, IMHO.

    Regards,
    Henrique Steckelberg
  51. Hibernate3 Filters[ Go to top ]

    You will get a FK violation exception.
  52. Side effects of using Filters[ Go to top ]

    Tested on Hibernate 3.0.5

    Be careful with filters and caches. First, if you use eager fetching somewhere you need to activate the filter before the eager fetching happens. That's somehow logical since the filters extend the SQL select statement. Then if you change the parameters of a filter in the middle of a session you need to care about the always enabled first level cache. Even re-get-ing your object won't put the filter (e.g. on a collection) into effect since the object is fetched from the first level cache. So you need to clear the first level cache or evict the object you want to re-get first.

    One thing I noticed is that the second level cache seems to be "disabled" by using filters. I have to investigate that further. I hope this is an error on my side, otherwise using filter could have a severe impact on the performance for all of us who rely on the second level cache.
  53. Re: Side effects of using Filters[ Go to top ]

    I used filters to implement an historical database (as per the example in the Hibernate manual). I had various issues, matching what you have described - and ended up having to alter two Hibernate classes to actually get the thing to allow non-eager fetching. (Performance was crippled without it - in fact a lot of queries would not even run on Oracle with eager fetching due to the DB complexity and limitations on the number of outer joins you can use in Oracle). I also implemented a Hibernate listener which automatically applies the filters when loading historical entities. I have spoken with Steve Ebersole but was unable to convince him that Hibernate need to implement a proper solution for historical databases using filters.