I have an existing (open-source) project (kind of CMS/DMS) where entities (from a customizeable data-model) can be persisted via an exchangeable component. Now I want to write an implementation for persistence using hibernate to gain all these benefits like abstraction from RDBMS, caching, etc. The thing is that my entities use a complex ID as primary key that is build of 3 parts: The first is a long that you can see as a normal generated id, the second is a redundant int that identifies the type of the entity (would be called Discriminator / DTYPE in context of hibernate) and a revision that is either 0 for the latest version or indicates the version of the entity in the versioning-history (similar to the optimistic locking version, but an explicit revision counter rather than just a modification-counter).
Now my question is: Can I make hibernate to work this way? I mean that hibernate accepts this complex ID, respects the "Discriminator" for creating proxies, etc. I also want to have the latest revisions of all resources in separate tables than the historic revisions (without using RDBMS specific features such as table-partitioning, triggers, etc.). Additionally I want to have a root-mapping for the abstract top-level entity type and concrete mapping for the non-abstract entities (what should work well with hibernate as far as I understood).
If I can do all this with hibernate, could you give me some hints to get started? I got lost in the documentation about such specific topics. Do I have to leave the Hibernate "API" and dive into the implementation to attain my goal?
Please note that I do not want to change the API of my entities (e.g. the way my IDs work).

As appendix an simple example to make it clear...
The ID is build out of UID, TYPE and REV.
The top-level table for all resources (all derived from MyRootEntity with fields "MyID id" and "String name") would look like this:

UID|TYPE|REV|Name|...
123|0001|003|Foo|...
124|0002|001|Bar|...
...

So we have the Resource "Foo" that is of TYPE "1" (associated with some sub-class of MyRootEntity) and the current revision is "3".

Now the top-level history table contains the versions "1" and "2" of "Foo".
UID|TYPE|REV|Name|...
123|0001|001|Foo-old-Name|...
123|0001|002|Foo|...

Please note that in the first table UID is unique while in the history it is only in combination with REV. Now if I lookup an ID with REV=0, I want to make a lookup in the first table and otherwise in the history table. The actual value of REV (in the example "003" for "Foo") could be stored in a separate field in MyRootEntity so the ID could still have REV=0.
This might look wiered at the first time but it allows me to save a lot of performance with lookups and filtering...