I don't follow your idea in #2 and #3 - is it related to StatelessSession ?
/max
As I say request for comments, so flaming is welcome.
1) A trivial thing being able to call delete on an object by only
knowing its OID.
Session.delete(Class klass, Serializable id);
This would for non-cascade object simply execute a delete statement and
evict any copy from the cache. For a class marked as always cascade
that has one or more relational columns it would force hibernate to do a
get then cascade delete the graph. The point being the application code
does not need to understand the cascade issue and the SELECT would be
optimised away by hibernate.
At the moment I have to do a:
MyObject rec = Session.get(MyObject.class, new Long(1));
if(rec != null) Session.delete(rec);
I would like to do:
Session.delete(MyObject.class, new Long(1));
This is a case that cropped up for me.
Simply creating a transient object and filling in the id field then
calling delete is not enough, since hibernate checks Nullable
constraints, so a real instance needs to be used.
2) Exposing the meta-data in a safe way for use within in-between
enviroments. "in-between" as in an enviorment where all data access to
tables by Hibernate may not be using hibernate itself to access. Mixed
database access with legacy systems, or legacy java code using JDBC.
This is really a way to re-use the hibernate meta-data in a more
primitive JDBC like way. Still keeping the POJO simplcity at the
programtic application end, the column mapping, data type conversion,
but providing a raw DB independant statement constructor.
So this issue boils down to a boilerplate statement constructor that
talks in terms of Object and HSQL syntax for SQL primitive SELECT,
INSERT, UPDATE and DELETE operations.
I'm happy even if there are huge provisos that using the API has
negative impact on pure hibernate access. This is okay as the
situations I have would be JDBC re-writes and would benifit from being
more portable through using hibernate in this way.
There would to be a document way of enforcing 100% reliable interaction
even if its to document a flush() before.
3) Extending issue 2 to be able to perform partial statements for
insert/update, this would provide helper / convienence API for common
uses of the above. I touched on what I'd like (from an application
programmers view) in my comments in
http://forum.hibernate.org/viewtopic.php?t=946803&highlight=
http://forum.hibernate.org/viewtopic.php?t=946712&highlight=#2258043
The difference here is that its less primitave and would have no (few)
interaction issues at all with mixing usage with general hibernate usage.
4) Age old one of improving SessionFactory startup in the development
enviroment. Max - You've given me enough pointers to not revisit this
one right here right now.
Max Rydahl Andersen wrote:
Whats the formal procedure to request additions to the existing APIs ?
post ideas here or in the jira.
patches helps good ideas to be adopted even faster.
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
[EMAIL PROTECTED]
http://hibernate.org
JBoss Inc
[EMAIL PROTECTED]
http://www.jboss.com/events/jbossworld
JBoss World Barcelona 10-12 October
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
