Hi Andreas,
I have some questions regarding RIFE´s persistence features.
1) Is the auto DatabaeSchema generation configurable ? For example:
Consider
a hierarchie, is it possible to say "save every class into its own
table" or
"save the complete hierarchie into one table"
No, it's not configurable, either you use CreateTable yourself,
either you rely on the automated rules that map beans to table. I'm
planning on adding the possibility to configure the properties
mappings and table names through constraints though.
2) How does RIFE cooperate with Hibernate ?
You can use both at the same time. The same datasource can be used,
the only problem that can arise is when instances in the OR manager
linger in cache and aren't found when RIFE is accessing the database
directly.
If I let RIFE create the Database-schema (auto-generated over a
MetaData
class), is it required to create a Hibernate Mapping file as well ?
No, you have to create nothing, it's all done by convention. However,
as said above the name mapping will become configurable.
3) is Lazy Fetching supported ? for instance fetching lazily
elements of a
list (instead of loading the complete list into the memory)
Yes, in the SVN repository we have lazy fetching for many-to-many
mappings. I'm still working on lazy fetching for single bean
instances as properties for one-to-one or many-to-one mappings.
4) what about cascading ?
You can use callbacks if you need to do cascading in Java, however
many database support this natively and you can just rely on that.
5) is there support for Second Level caching ?
Not natively, this is also something that can be added through
callbacks and / or GQM listeners. I do think that at one time
something better integrated should be developed.
6) is there anything missing (compared to Hibernate, or other
Persistence
frameworks) ?
A lot, since they are different beasts and if you need the power of
JPA or Hibernate, by all means, use those. RIFE doesn't provide an
ORM solution with an entity manager and such. It doesn't provide
table hierarchies, not composite keys. The GQM is currently also
limited to integers as identifiers, ... and so on. However, the
approach is a wrapping approach that basically put layers on top of
what you would normally do in plain JDBC and SQL. The APIs give you a
much higher level approach to achieve the same functionalities while
still being able to drill down when needed.
Hope this helps,
Geert
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
Rife-users mailing list
Rife-users@uwyn.com
http://lists.uwyn.com/mailman/listinfo/rife-users
