Well that's the thing... if I knew the answer to all of those I'd already have done the work First, following on Mike Reid's comment regarding implementing this at the database level is always better in my experience. But in cases where people choose to go this route for whatever reason, I think it's doable (mostly[1]) at the database level. The first thing is to come to a consensus on the preliminary design. The main question is how to handle the discriminator value at the JDBC level... param binding or literal? I think we should support just a single config param at the persistence-unit level to allow defining how this should be handled and that we should default to parameter. For sure you'd have to look at the EntityPersister and CollectionPersister contracts as those handle generating most of the "fragments" of SQL that get pieced together. These changes would have to account for the internal cache of SQL statements kept on each of these impls (mostly through AbstractEntityPersister and AbstractCollectionPersister). Personally I'd suggest we target this for 6.x. The new persister model there is much better suited to this use-case, IMO. Beyond that Oogledy Poogledy, TheDevilsInTheDetails(tm). It's not until someone starts digging into an actual implementation that we will understand all the implications. [1] We'd currently not effectively be able to filter native sql queries which is something we'd really need to define. |