Re: [hibernate-dev] Contributed with HiRDB Dialect

2008-09-17 Thread Chris Bredesen 

Tomoto-san,

I've had a conversation with Steve regarding the addition of new 
Dialects such as the one you've proposed.  Here are the options:


1. Integrate a new org.hibernate.dialect.HiRDBDialect into Hibernate's 
source code.  This is reasonable for mainstream highly used databases 
that most users would expect us to provide support for.  In this 
scenario, there's an implied responsibility on behalf of the Hibernate 
team to ensure that they remain usable as Hibernate and the RDBMS 
evolves.  While it's great to get contributions for new and interesting 
platforms, sometimes this happens "one time only" and in 5 years, we're 
left with a Dialect that nobody can use and nobody is available to 
maintain it.


2. Integrate a new org.hibernate.dialect.HiRDDialect into an optional 
distribution that users are free to download and use at their leisure. 
This is a good choice for less used integration pieces that may be less 
actively maintained than core code.  We are open to this for your case 
but it would take some time to set up (Steve can comment on exactly when 
this might take place).


3. Ship HiRDBDialect as a download from hitachi.co.jp or part of the 
HiRDB JDBC distribution (in a com.hitachi.* package).  I actually like 
this option a lot because it is clear who owns/maintains the code. 
Also, new versions of the Dialect can be shipped as HiRDB evolves and 
releases new versions.  Including it with the JDBC driver would make the 
Hibernate dialect available automatically to anyone who needs it.


What do you think of option 3?  Is this something you can facilitate 
along with the team that maintains the JDBC driver?  We will be happy to 
provide links to the downloadable Dialect on hibernate.org so that users 
can find things easily.  If this is not an option, I'll discuss the 
creation of an "extras" module that can house code like this.  We may 
have to do this already because there are some existing bits of code 
that really should not be part of the core distribution for reasons 
outlined above.


There's also the issue of testing.  I don't envision acquiring hardware 
and licenses to HiRDB so that we can make it part of our QA suite. 
Shipping a Dialect as part of the core distribution tends to give users 
the impression that we are 100% confident in its quality (even if our 
web site says differently).  We clearly can't be 100% confident in code 
quality when we don't actively test against a given scenario.  Based on 
this I think option 3 is the best but please let me know if this can 
work for you.


Cheers,

Chris

Tomoto Shimizu Washio wrote:

Hi Chris,

Unfortunately, there is no free version of HiRDB.  I think I could do
(a) running the tests in our side and sending you the result or
(b) getting a copy for you from my organization (perhaps arranging some
kind of contract would be required but I'm not sure).  Which do you want
me to do?

I guess (a) is easier for both of us if you don't have to keep HiRDB
with you for regular testing.  I already have the test result on 3.2.5.
If you would like me to test on another version, I could do it also.

Thanks,
Tomoto


On Fri, 05 Sep 2008 13:35:00 -0400
Chris Bredesen <[EMAIL PROTECTED]> wrote:


Tomoto,

Thank you for the contribution!  Is there somewhere that one might 
obtain a copy of HiRDB to run the unit tests against?


-Chris

[EMAIL PROTECTED] wrote:

Hi, my name is Tomoto at Software Division in Hitachi.

I have posted a dialect for HiRDB (Hitachi's RDBMS, see *1) to JIRA.
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3465

I would appreciate it if someone in the team could take a look at it
for evaluation, and I would be happy to solve the issues you saw if
any.  I really wish this dialect to be incorporated into Hibernate
so that our customers could easily use Hibernate on HiRDB.

This dialect comes with a feature to allow the user to declare the
parameter types of user-defined functions in the properies file. It
was necessary because HiRDB required ? parameters to be qualified by
'as ' in user-defined function invocations.  If there were
other databases that required the similar feature, and if you thought
my implementation was good enough to let them use, I might be able to
make an entry point on the Dialect base class so that other subclasses
could use it more easily.

*1 http://www.hitachi.co.jp/Prod/comp/soft1/global/prod/hirdb/

Thank you in advance,



___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Mutable natural key caching?

2008-09-17 Thread Steve Ebersole 
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2879 ???

-  

Steve Ebersole
Project Lead
http://hibernate.org
[EMAIL PROTECTED]

Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
[EMAIL PROTECTED]
[EMAIL PROTECTED]


On Tue, 2008-09-16 at 10:03 -0700, Elias Ross wrote:
> I've been looking to optimize the caching of an application which uses
> a mutable natural key, an account phone number.
> 
> Hibernate does not yet support optimized caching of
> @NaturalId(mutable=false), because of how the current natural ID
> relies on immutable IDs. The caching associates a QueryKey -> results
> and it's impossible to evict the QueryKey since the natural keys are
> embedded in it.
> 
> One solution I considered was to create an association between a set
> of natural ID values and "QueryKey". When a query is made with mutable
> natural keys, an association would be made. This could be done within
> "StandardQueryCache." And then when an entity is updated or removed,
> if there are mutable natural keys, Hibernate could locate the query
> and remove it as well. I'm not sure how I could implement this part.
> I'm guessing I'd have to add a method to QueryCache to do the removal.
> 
> public interface QueryCache {
> 
> ...
>   public void remove(NaturalIdAssocation nia) throws HibernateException;
> 
> }
> 
> public class NaturalIdAssociation implements Serializeable {
>   Type type;
>   Set keys;
> }
> 
> Actually, thinking this over, having this removal operation would fix
> some other issues when non-mutable natural id entities are removed.
> For instance, HHH-3478, a problem found using EntityManager and
> natural IDs.
> 
> Thoughts?
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Mutable natural key caching?

2008-09-17 Thread Elias Ross 
On Wed, Sep 17, 2008 at 9:12 PM, Steve Ebersole <[EMAIL PROTECTED]> wrote:
> http://opensource.atlassian.com/projects/hibernate/browse/HHH-2879 ???
>

If you use Hibernate EntityManager, get the Hibernate Session and use
Criteria to query by natural ID and the entity was deleted, you end up
with an EntityNotFoundException. I reported the issue as: HHH-3478

I have a patch which fixes this problem, but it's a hack. From the issue:

In StandardQueryCache, there is a "catch" which handles
"UnresolvableObjectException" but not "EntityNotFoundException"

catch ( UnresolvableObjectException uoe ) {
  if ( isNaturalKeyLookup ) {
  //TODO: not really completely correct, since
  // the uoe could occur while resolving
  log.debug( "could not reassemble cached result set" );
  cacheRegion.evict( key );
  return null;
}

I'm thinking that by keeping an association mapped in the query cache
-- but I'm thinking that's not the right spot --
EntityManager/Session.remove() could trigger a removal of any natural
ID criteria query as well. And so could any update, if the natural IDs
were mutable. Anyway, you'd get rid of this hack, possibly.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev