Re: [hibernate-dev] org.hibernate.engine.jdbc.dialect.spi.DialectResolver
and having On 31 Aug 2012, at 01:59, Steve Ebersole wrote: > Correct. The current proposal has them passed in as settings. okey, so I must be missing something - since no access to database metadata how is the autodetection of name/version supposed to work when users have not passed in the settings ? > Yes, we could "mock" DatabaseMetadata, but there is a lot there including > access to the Connection from which the DatabaseMetadata was supposedly > retrieved. And something like would be too weird: public Dialect resolveDialect(String dbname, String version, DatabaseMetaData dbmetadata) Where dbmetadata is null if not available ? /max > On Thu 30 Aug 2012 02:31:56 AM CDT, Emmanuel Bernard wrote: >> I imagine the DB name + version will be provided by the user somehow. >> We could also have Hibernate build a DatabaseMetadata implementation >> returning the data provided by the user. >> That would avoid changing the contract. The main drawback is that >> DatabaseMetadata has many more methods >> we would not be able to honor. >> >> On 29 août 2012, at 19:58, Steve Ebersole wrote: >> >>> Like I said in the original email, the connection may or may not be >>> available. Which means we cannot rely on it being available. Nor do >>> we rely on it being available today either btw. The difference is just >>> that today in those cases we expect the user to manually name the >>> dialect to use. >>> >>> On Wed 29 Aug 2012 12:26:17 PM CDT, Max Rydahl Andersen wrote: hmm - any reason why jpa won't pass in DatabaseMetadata ? how would one identify name and version anyway if that is not available ? /max On 29 Aug 2012, at 16:43, Steve Ebersole wrote: > I think we need to consider changing DialectResolver to fit with some > upcoming JPA 2.1 features. > > JPA 2.1 is adding some form of schema export. The initial plan there is > to identify the "dialect" to target by passing in the (1) database name > and (2) database version as it would come from JDBC DatabaseMetaData. > The connection may or may not be available. > > Currently we just pass the DatabaseMetaData to the DialectResolver: > > public Dialect resolveDialect(DatabaseMetaData metaData) > > The original thinking was to support resolvers looking at information > other than just name/version ion making the determination (or even in > potentially configuring the Dialect before return). However all our > implementations are based on just name/version resolution. > > Even worse the current proposal proposes using (String) > DatabaseMetaData#getDatabaseProductVersion whereas we use (int) > DatabaseMetaData#getDatabaseMajorVersion and (int) > DatabaseMetaData#getDatabaseMinorVersion inside the standard resolver > > So should we change this contract? > > public Dialect resolveDialect(String dbName, int majorVersion, int > minorVersion) > > or > > public Dialect resolveDialect(String dbName, String dbVersion) > > WDYT? > > -- > st...@hibernate.org > http://hibernate.org > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> -- >>> st...@hibernate.org >>> http://hibernate.org >>> ___ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > -- > st...@hibernate.org > http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Metamodel dev questions
Hi,
I just bumped into a couple of issues when working on some metamodel tests.
First thing I came across was a NullPointerException :-( Turns out I was
missing to add a annotated class to the test.
Digging a little deeper I noticed that the problem is in the Binder. It does
something like:
final EntitySource entitySource =
entitySourcesByName.get( entityName );
final EntityBinding superEntityBinding =
SubclassEntitySource.class.isInstance(
entitySource )
? entityBinding( ( (
SubclassEntitySource ) entitySource ).superclassEntitySource().getEntityName() )
: null;
If the user for some reason forgets to add all configuration sources he will
just get a NullPointerException. Not nice :-(
It seems this is a general problem in the Binder atm. We have to better cater
for border cases and think about
potential problems and how we can provide useful feedback.
Next, I tried to change this to
final EntitySource entitySource =
entitySourcesByName.get( entityName );
if(entitySource == null) {
throw coreLogger.missingEntitySourceException(
entityName );
}
// Get super entity binding (creating it if necessary
using recursive call to this method)
final EntityBinding superEntityBinding =
SubclassEntitySource.class.isInstance(
entitySource )
? entityBinding( ( (
SubclassEntitySource ) entitySource ).superclassEntitySource().getEntityName() )
: null;
where I added the following to CoreMessageLogger:
@Message(value = "Unable to find mapping information for %s. Are you sure all
annotated classes and configuration files are added?", id = 443)
/MappingException missingEntitySourceException(String entityName);
I just want to get a i18n exception. When doing so, the generation of the
logger classes fails!
org.gradle.api.tasks.TaskExecutionException: Execution failed for task
':hibernate-core:generateMainLoggingClasses'.
at
org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:68)
at
org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:46)
at
org.gradle.api.internal.tasks.execution.PostExecutionAnalysisTaskExecuter.execute(PostExecutionAnalysisTaskExecuter.java:34)
at
org.gradle.api.internal.changedetection.CacheLockHandlingTaskExecuter$1.run(CacheLockHandlingTaskExecuter.java:34)
at
org.gradle.cache.internal.DefaultCacheAccess$2.create(DefaultCacheAccess.java:200)
at
org.gradle.cache.internal.DefaultCacheAccess.longRunningOperation(DefaultCacheAccess.java:172)
at
org.gradle.cache.internal.DefaultCacheAccess.longRunningOperation(DefaultCacheAccess.java:198)
at
org.gradle.cache.internal.DefaultPersistentDirectoryStore.longRunningOperation(DefaultPersistentDirectoryStore.java:137)
at
org.gradle.api.internal.changedetection.DefaultTaskArtifactStateCacheAccess.longRunningOperation(DefaultTaskArtifactStateCacheAccess.java:83)
at
org.gradle.api.internal.changedetection.CacheLockHandlingTaskExecuter.execute(CacheLockHandlingTaskExecuter.java:32)
at
org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:55)
at
org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:57)
at
org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:41)
at
org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:51)
at
org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:52)
at
org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:42)
at
org.gradle.api.internal.AbstractTask.executeWithoutThrowingTaskFailure(AbstractTask.java:247)
at
org.gradle.execution.DefaultTaskGraphExecuter.executeTask(DefaultTaskGraphExecuter.java:192)
at
org.gradle.execution.DefaultTaskGraphExecuter.doExecute(DefaultTaskGraphExecuter.java:177)
at
org.gradle.execution.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:83)
at
org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTaskExecutionAction.java:36)
at
org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:61)
at
org.gradle.execution.DefaultBuild
Re: [hibernate-dev] org.hibernate.engine.jdbc.dialect.spi.DialectResolver
On Aug 31, 2012 3:02 AM, "Max Rydahl Andersen" wrote: > > and having > > On 31 Aug 2012, at 01:59, Steve Ebersole wrote: > > > Correct. The current proposal has them passed in as settings. > > okey, so I must be missing something - since no access to database metadata how is the autodetection of name/version supposed to work when users have not passed in the settings ? Two different things: 1) Auto-detection is something we do while building the sessionfactory. 2) JPA defined schema export which Linda wants to have work even when the database is not available (no different from our current SchemaExport really) Auto-detection while building the sessionfactory *will* have access to the dba metadata or building the sessionfactory will fail. Though maybe we also add recognition of these JPA config values, then determining dialect would be: 1) explicit dialect 2) explicit JPA db/version sittings 3) querying the jdbc metadata, if available 4) fail That is actually exactly what we do today except that (2) would be new addition. The argument against adding (2) is that these JPA settings are meant for a very specific purpose > > > Yes, we could "mock" DatabaseMetadata, but there is a lot there including access to the Connection from which the DatabaseMetadata was supposedly retrieved. > > And something like would be too weird: > > public Dialect resolveDialect(String dbname, String version, DatabaseMetaData dbmetadata) > > Where dbmetadata is null if not available ? Well that is an option. Let's see what others think. But I am not a fan of passing in just the single String version. I brought this up to the JPA group too and it looks like this will change there to allow access to (int) major/minor. > > /max > > > On Thu 30 Aug 2012 02:31:56 AM CDT, Emmanuel Bernard wrote: > >> I imagine the DB name + version will be provided by the user somehow. > >> We could also have Hibernate build a DatabaseMetadata implementation returning the data provided by the user. > >> That would avoid changing the contract. The main drawback is that DatabaseMetadata has many more methods > >> we would not be able to honor. > >> > >> On 29 août 2012, at 19:58, Steve Ebersole wrote: > >> > >>> Like I said in the original email, the connection may or may not be > >>> available. Which means we cannot rely on it being available. Nor do > >>> we rely on it being available today either btw. The difference is just > >>> that today in those cases we expect the user to manually name the > >>> dialect to use. > >>> > >>> On Wed 29 Aug 2012 12:26:17 PM CDT, Max Rydahl Andersen wrote: > hmm - any reason why jpa won't pass in DatabaseMetadata ? > > how would one identify name and version anyway if that is not available ? > > /max > > On 29 Aug 2012, at 16:43, Steve Ebersole wrote: > > > I think we need to consider changing DialectResolver to fit with some > > upcoming JPA 2.1 features. > > > > JPA 2.1 is adding some form of schema export. The initial plan there is > > to identify the "dialect" to target by passing in the (1) database name > > and (2) database version as it would come from JDBC DatabaseMetaData. > > The connection may or may not be available. > > > > Currently we just pass the DatabaseMetaData to the DialectResolver: > > > > public Dialect resolveDialect(DatabaseMetaData metaData) > > > > The original thinking was to support resolvers looking at information > > other than just name/version ion making the determination (or even in > > potentially configuring the Dialect before return). However all our > > implementations are based on just name/version resolution. > > > > Even worse the current proposal proposes using (String) > > DatabaseMetaData#getDatabaseProductVersion whereas we use (int) > > DatabaseMetaData#getDatabaseMajorVersion and (int) > > DatabaseMetaData#getDatabaseMinorVersion inside the standard resolver > > > > So should we change this contract? > > > > public Dialect resolveDialect(String dbName, int majorVersion, int > > minorVersion) > > > > or > > > > public Dialect resolveDialect(String dbName, String dbVersion) > > > > WDYT? > > > > -- > > st...@hibernate.org > > http://hibernate.org > > ___ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >>> > >>> -- > >>> st...@hibernate.org > >>> http://hibernate.org > >>> ___ > >>> hibernate-dev mailing list > >>> hibernate-dev@lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > > > -- > > st...@hibernate.org > > http://hibernate.org > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss
Re: [hibernate-dev] Metamodel dev questions
In terms of exception handling, of course you are right in terms of
final product.
IIUC that not how use of jboss-logging for generating exception messages
is supposed to work, though to be honest, I do not know the details.
Since you "use this in Validator and Search" I would figure you would
know how to do it.
The "purpose of the annotation processor" is couple-fold, but here the
intention is to handle i18n of the logged messages, same as it would for
exception messages that you want...
On 08/31/2012 05:23 AM, Hardy Ferentschik wrote:
> Hi,
>
> I just bumped into a couple of issues when working on some metamodel tests.
>
> First thing I came across was a NullPointerException :-( Turns out I was
> missing to add a annotated class to the test.
> Digging a little deeper I noticed that the problem is in the Binder. It does
> something like:
>
> final EntitySource entitySource =
> entitySourcesByName.get( entityName );
> final EntityBinding superEntityBinding =
> SubclassEntitySource.class.isInstance(
> entitySource )
> ? entityBinding( ( (
> SubclassEntitySource ) entitySource
> ).superclassEntitySource().getEntityName() )
> : null;
>
> If the user for some reason forgets to add all configuration sources he will
> just get a NullPointerException. Not nice :-(
> It seems this is a general problem in the Binder atm. We have to better cater
> for border cases and think about
> potential problems and how we can provide useful feedback.
>
> Next, I tried to change this to
>
> final EntitySource entitySource =
> entitySourcesByName.get( entityName );
> if(entitySource == null) {
> throw coreLogger.missingEntitySourceException(
> entityName );
> }
>
> // Get super entity binding (creating it if necessary
> using recursive call to this method)
> final EntityBinding superEntityBinding =
> SubclassEntitySource.class.isInstance(
> entitySource )
> ? entityBinding( ( (
> SubclassEntitySource ) entitySource
> ).superclassEntitySource().getEntityName() )
> : null;
>
> where I added the following to CoreMessageLogger:
>
> @Message(value = "Unable to find mapping information for %s. Are you sure all
> annotated classes and configuration files are added?", id = 443)
> /MappingException missingEntitySourceException(String entityName);
>
> I just want to get a i18n exception. When doing so, the generation of the
> logger classes fails!
>
> org.gradle.api.tasks.TaskExecutionException: Execution failed for task
> ':hibernate-core:generateMainLoggingClasses'.
> at
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:68)
> at
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:46)
> at
> org.gradle.api.internal.tasks.execution.PostExecutionAnalysisTaskExecuter.execute(PostExecutionAnalysisTaskExecuter.java:34)
> at
> org.gradle.api.internal.changedetection.CacheLockHandlingTaskExecuter$1.run(CacheLockHandlingTaskExecuter.java:34)
> at
> org.gradle.cache.internal.DefaultCacheAccess$2.create(DefaultCacheAccess.java:200)
> at
> org.gradle.cache.internal.DefaultCacheAccess.longRunningOperation(DefaultCacheAccess.java:172)
> at
> org.gradle.cache.internal.DefaultCacheAccess.longRunningOperation(DefaultCacheAccess.java:198)
> at
> org.gradle.cache.internal.DefaultPersistentDirectoryStore.longRunningOperation(DefaultPersistentDirectoryStore.java:137)
> at
> org.gradle.api.internal.changedetection.DefaultTaskArtifactStateCacheAccess.longRunningOperation(DefaultTaskArtifactStateCacheAccess.java:83)
> at
> org.gradle.api.internal.changedetection.CacheLockHandlingTaskExecuter.execute(CacheLockHandlingTaskExecuter.java:32)
> at
> org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:55)
> at
> org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:57)
> at
> org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:41)
> at
> org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:51)
> at
> org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:52)
> at
> org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:42)
>
Re: [hibernate-dev] Metamodel dev questions
On 31 Aug 2012, at 13:49, Steve Ebersole wrote: > In terms of exception handling, of course you are right in terms of final > product. I understand we are in a transition phase. Just saying that we should keep it in mind already now and IMO add the obvious checks already now. > IIUC that not how use of jboss-logging for generating exception messages is > supposed to work, though to be honest, I do not know the details. Since you > "use this in Validator and Search" I would figure you would know how to do it. The way I tried is afaik the way it should work, hence I wad so surprised that it did not work. I was hoping someone already came across this or that we maybe by design not use it. I guess I have to just dig a little deeper. Unfortunately, part of the exception seems to get swallowed (even with --stacktrace and --debug enabled) :-( --hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Metamodel dev questions
On 31 Jan 2012, at 1:46 PM, Steve Ebersole wrote: > IIUC that not how use of jboss-logging for generating exception messages is > supposed to work, though to be honest, I do not know the details. Since you > "use this in Validator and Search" I would figure you would know how to do it. Turns out it is another classical chicken and egg problem. I tried to return a MappingException which is at the time the annotation processor runs not compiled yet (In Search and Validator we use exceptions which are available on the classpath). A solution would be to first compile exceptions prior to running the annotation processor, but that would make the build even more complicated. The alternative is to just return a string @Message(value = "Unable to find mapping information for %s. Are you sure all annotated classes and configuration files are added?", id = 443) String missingEntitySource(String entityName); and use this string in the exception constructor. --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate Envers question
Hello! I wondered how envers works/could work in a JPA portable way. Are you using somehow a entity listener approach or so? Does the the code needed for envers really depend on the hibernate core stuff or does hibernate just offer a more relaxed contract in respect to entity listeners? I was just wondering why nobody proposed the auditing stuff to be included in the jpa spec since there were already many requests for auditing for other jpa impls. IMO it's a fairly common issue to address auditing and therefore worth to, not necessarily be standardized but, at least be provider independent. I don't have a problem with hibernate at all, I will go on using it since it's just great, but the question just came up in my head and I wanted to know if you maybe already discussed something like that with the jpa team? Regards, Christian ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
