[Hibernate] Kudos, Exception question, Validatable...
First of all, since picking up Hibernate on a project and using it for a month or two (and having used a few other similar systems), and having some occasions to hunt around in the source, I wanted to write just to say that I was impressed by the clarity, concision, and overall good experience I'm having with the code. My hat is off to everyone involved! Thank you for writing this cool thing. Second, my question. I have an persistent bean with a String property that has a short column length. A Swing GUI presents existing and eventually provides new contents for this property. There are a variety of ways that I can configure the "interface" to insure the String isn't too long, but in the process of thinking about it I noticed that, when the string _is_ too long, I get a JDBCException at commit time, from which I can extract the database's message... but since this is at commit time, and I am committing changes to a number of objects, I cannot identify what, if any, persistent object is associated with the error. It seems to me this could be a useful thing to know. In looking around it seems like it would be easy to subclass JDBCException to provide an extra property (i.e. JDBCEntityException.getEntity()), and create them with some simple modifications in EntityPersister/NormalizedEntityPersister. Is this a bad idea? Good one? Please go easy on the new guy. :) And then as I consider alternatives, I consider making the bean Validateable, and ideally using a utility class to check the String properties against length values in the persistence metadata. But when I look through ClassMetadata and Type, I can't find the "length." Am I missing it? Or is it not there? Once again, thanks, David --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Kudos, Exception question, Validatable...
> hmmmdon't know if it would be great to hold a reference to an object > in the exception...but maybe extend the message with information > (textual representation of the object) would probably be ok OK. So, add a toString() to the JDBCException's message. It's a good idea. I want to make sure I understand your concern. While I see the need to be circumspect about this sort of thing, I'm having trouble thinking of cases where holding the reference in the Exception could actually cause a problem. We're talking about times where the Exception will outlast the Object, right? Please, this is purely hypothetical - I'm just trying to learn about how things work. > >And then as I consider alternatives, I consider making the bean > >Validateable, and ideally using a utility class to check the String > >properties against length values in the persistence metadata. But when I > >look through ClassMetadata and Type, I can't find the "length." Am I > >missing it? Or is it not there? > > > > > It is available from Configurations metadata. Thanks! I see it now. I was thrown off by the manual's directions regarding the metadata available via SessionFactory. For the benefit of the archives: Configuration.getClassMapping(), to getProperty(), to getColumnIterator(), to getLength() on the Column object. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] New subproject proposal: a batching, client/server JDBC layer
I just did a swing client that uses hibernate, and although in my case I
was alright to make the database available to the client hosts, I'm sure
many can't. So it sounds like this will certainly be useful, but it has me
thinking: will this layer be added only because nobody trusts the
database's security ("I can't expose my DB to the world because someone
will get in")? Or perhaps because the DB's security model is "too general"
and therefore too difficult for people to secure properly ("I can't safely
make a 'restricted' user because I'll accidently - or necessarily - leave
it with dangerous privileges")?
Of course, whether directly or through a JDBC wrapper, a user can always
extract the security privileges from a client and circumvent any
restrictions imposed by that application; read any row or send a few
"delete from..." So I can see an argument for something more fine-grained
or custom wrapping the database to ensure that it really behaves like a
proper "server application" and only expected operations are allowed,
security policy is enforced, etc. It's not clear how that works with
Hibernate... by using stored procedures somehow? Or, perhaps, Hibernate
really lives on the server after all, and the whole client works via
RMI/SOAP etc and is "thinner."
I am used to people treating their DB like a windows box, hiding it behind
firewalls, etc. I certainly see the sense in it. And this is really not
practical, but in theory at least, wouldn't it be better to fix the
database (whichever one it is) rather than wrapping it, if we trust it
this little? Or is it impossible to safely expose the database at all,
through a wrapper or not?
[EMAIL PROTECTED] wrote on 06/14/2004 08:44:23
AM:
> I've been thinking about the problem of users who ask for
> "lazy fetching from the client". As we keep explaining,
> this is an incredibly bad idea, since transaction
> demarcation and caching (and probably also dirty checking)
> should take place in the same tier as lazy fetching.
>
> However, many of these users are writing Swing or rich client
> applications and I think perhaps the reason they ask for this
> is that they are forced to run Hibernate in the server tier
> since they are not allowed to open a JDBC connection from the
> client, and Hibernate is tied to the JDBC connection pool.
>
> After thinking about this, I think I've decided that there is
> nothing at all wrong with doing data access via a remote
> "gateway", so that Hibernate would run in the client tier and
> act as a remote client of a server-side JDBC connection pool.
> This would enable transaction demarcation, caching, dirty
> checking and lazy fetching to be done on the client, but the
> actual database access would take place on the server.
>
> Now, as far as I can see, there is no reason at all for this
> to be implemented as part of the ORM solution. Indeed, it
> makes much more sense for this to be simply wrapper abound
> JDBC. The wrapper would do transparent batching of
> INSERT/UPDATE/DELETEs and provide pluggable client/server
> remotability strategies (RMI/SOAP/etc), delegating to
> a server-side connection pool. It could even be used outside
> of Hibernate.
>
> Does anyone know of an existing project like this? If not,
> should we start one, under the aegis of hibernate.org? Is
> anyone interested in starting work on this. I'm convinced
> it is not at all difficult to implement.
>
> Have I gone insane?
>
> --
> Gavin King
> +61 41 053 4454
> +1 404 822 8349
>
> Hibernate
> [EMAIL PROTECTED]
> http://hibernate.org
>
> JBoss Inc
> [EMAIL PROTECTED]
> http://jboss.com
>
>
>
> ---
> This SF.Net email is sponsored by the new InstallShield X.
> From Windows to Linux, servers to mobile, InstallShield X is the
> one installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> ___
> hibernate-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
---
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
___
hibernate-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] New subproject proposal: a batching, client/server JDBC layer
Yes, I think you're right. Apparently, depending on the requirements of
the project, the client may as well either run Hibernate and speak
directly with the database, or (if you're concerned about security and
have the time) that both JDBC and Hibernate must be on the server. Clients
should generally follow the latter design - certainly if they are exposed
to the world. But I can imagine in many cases the former shortcut may be
necessary or even appropriate...
Gavin King <[EMAIL PROTECTED]> wrote on 06/14/2004 10:33:24 AM:
> OK, so the problem is that this JDBC proxy still allows arbitrary SQL to
> be executed on the server. Never worked with rich client applications
> before, I had not realized that this (security) was the main reason for
> choosing to add a third tier. I thought the problem was minimizing
database
> connections for license/scalability purposes.
>
> I guess this argument against doing it at the JDBC level also applies
> to doing it at the ORM level, since it still opens up the possibility of
> arbitrary queries.
>
>
> David Wood wrote:
>
> >I just did a swing client that uses hibernate, and although in my case
I
> >was alright to make the database available to the client hosts, I'm
sure
> >many can't. So it sounds like this will certainly be useful, but it has
me
> >thinking: will this layer be added only because nobody trusts the
> >database's security ("I can't expose my DB to the world because someone
> >will get in")? Or perhaps because the DB's security model is "too
general"
> >and therefore too difficult for people to secure properly ("I can't
safely
> >make a 'restricted' user because I'll accidently - or necessarily -
leave
> >it with dangerous privileges")?
> >
> >Of course, whether directly or through a JDBC wrapper, a user can
always
> >extract the security privileges from a client and circumvent any
> >restrictions imposed by that application; read any row or send a few
> >"delete from..." So I can see an argument for something more
fine-grained
> >or custom wrapping the database to ensure that it really behaves like a
> >proper "server application" and only expected operations are allowed,
> >security policy is enforced, etc. It's not clear how that works with
> >Hibernate... by using stored procedures somehow? Or, perhaps, Hibernate
> >really lives on the server after all, and the whole client works via
> >RMI/SOAP etc and is "thinner."
> >
> >I am used to people treating their DB like a windows box, hiding it
behind
> >firewalls, etc. I certainly see the sense in it. And this is really not
> >practical, but in theory at least, wouldn't it be better to fix the
> >database (whichever one it is) rather than wrapping it, if we trust it
> >this little? Or is it impossible to safely expose the database at all,
> >through a wrapper or not?
> >
> >
>
>
> --
> Gavin King
> +61 41 053 4454
> +1 404 822 8349
>
> Hibernate
> [EMAIL PROTECTED]
> http://hibernate.org
>
> JBoss Inc
> [EMAIL PROTECTED]
> http://jboss.com
>
---
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
___
hibernate-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] one-to-many relationships, outer joins with "fetch" HQL, and redundant results.
Outer join fetching has never been good to me. Hibernate always seemed to ignore my OJ configuration settings and metadata, at least for where it mattered for me (on collections). Eventually I discovered the correct language in HQL queries to "force" it to happen: "from Parent as p left join fetch p.children". This works, and at last my round-tripping ended. But what I got back from find() was unexpected; when a Parent has multilpe Children, I got multiple references to the Parent in the result List! OK, sure, in a way it seems obvious... the SELECT returns extra rows, you get extra references. But it seemed like an unexpected violation of the illusion of Object-centrism that I had come to expect from Hibernate. I spent time today hunting through Loader but am still unsure if this is a bug or a feature. Any comments? --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND ___ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
