You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by GitBox <gi...@apache.org> on 2021/02/08 19:15:11 UTC
[GitHub] [isis] andi-huber opened a new pull request #373: ISIS-2502: working on Exception Recognizers
andi-huber opened a new pull request #373:
URL: https://github.com/apache/isis/pull/373
Provide test cases for:
1. ExceptionRecognizerForDataAlreadyExists
2. ExceptionRecognizerForObjectNotFound
3. ExceptionRecognizerForRelatedDataExists
4. ExceptionRecognizerForUnableToSaveData
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [isis] andi-huber edited a comment on pull request #373: ISIS-2502: working on Exception Recognizers
Posted by GitBox <gi...@apache.org>.
andi-huber edited a comment on pull request #373:
URL: https://github.com/apache/isis/pull/373#issuecomment-775657475
- [x] JPA: `SQLIntegrityConstraintViolationException` is not an instance of `RuntimeException`, so cannot be passed to the built-in ex. translation utilities ... ending up with a too generic` DataAccessException`
- [x] JDO: On unique constraint violation, we get a `NucleusDataStoreException` that translates to `JDODataStoreException` that does not translate to `DataIntegrityViolationException`
- [x] DefaultJdoDialect has no `SQLExceptionTranslator` set, so relies on the JDO provider's native exception translation
- [ ] Datanucleus: On unique constraint violation, wraps a `NucleusDataStoreException` with an `IllegalArgumentException` which obscures further translation attempts
- [ ] maybe `JdoEntityFacet` and `JpaEntityFacet` are the right places, where we want to do the ex. translation logic
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [isis] andi-huber edited a comment on pull request #373: ISIS-2502: working on Exception Recognizers
Posted by GitBox <gi...@apache.org>.
andi-huber edited a comment on pull request #373:
URL: https://github.com/apache/isis/pull/373#issuecomment-775657475
- [x] JPA: `SQLIntegrityConstraintViolationException` is not an instance of `RuntimeException`, so cannot be passed to the built-in ex. translation utilities ... ending up with a too generic` DataAccessException`
- [x] JDO: On unique constraint violation, we get a `NucleusDataStoreException` that translates to `JDODataStoreException` that does not translate to `DataIntegrityViolationException`
- [x] DefaultJdoDialect has no `SQLExceptionTranslator` set, so relies on the JDO provider's native exception translation
- [ ] Datanucleus: On unique constraint violation, wraps a `NucleusDataStoreException` with an `IllegalArgumentException` which obscures further translation attempts
- [ ] TransactionService (Isis) should not translate exceptions, there is no point, since not all transactions are gated by it
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [isis] andi-huber edited a comment on pull request #373: ISIS-2502: working on Exception Recognizers
Posted by GitBox <gi...@apache.org>.
andi-huber edited a comment on pull request #373:
URL: https://github.com/apache/isis/pull/373#issuecomment-775657475
- [x] JPA: `SQLIntegrityConstraintViolationException` is not an instance of `RuntimeException`, so cannot be passed to the built-in ex. translation utilities ... ending up with a too generic` DataAccessException`
- [x] JDO: On unique constraint violation, we get a `NucleusDataStoreException` that translates to `JDODataStoreException` that does not translate to `DataIntegrityViolationException`
- [x] DefaultJdoDialect has no `SQLExceptionTranslator` set, so relies on the JDO provider's native exception translation
- [ ] Datanucleus: On unique constraint violation, wraps a `NucleusDataStoreException` with an `IllegalArgumentException` which obscures further translation attempts
- [ ] maybe `JdoEntityFacet` and `JpaEntityFacet` are the right places, where we want to do the ex. translation logic (that is, translate anything we catch to _Spring's_ `DataAccessException` hierarchy)
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [isis] andi-huber edited a comment on pull request #373: ISIS-2502: working on Exception Recognizers
Posted by GitBox <gi...@apache.org>.
andi-huber edited a comment on pull request #373:
URL: https://github.com/apache/isis/pull/373#issuecomment-775657475
- [x] JPA: `SQLIntegrityConstraintViolationException` is not an instance of `RuntimeException`, so cannot be passed to the built-in ex. translation utilities ... ending up with a too generic` DataAccessException`
- [ ] JDO: On unique constraint violation, we get a `NucleusDataStoreException` that translates to `JDODataStoreException` that does not translate to `DataIntegrityViolationException`
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [isis] andi-huber edited a comment on pull request #373: ISIS-2502: working on Exception Recognizers
Posted by GitBox <gi...@apache.org>.
andi-huber edited a comment on pull request #373:
URL: https://github.com/apache/isis/pull/373#issuecomment-775657475
- [x] JPA: `SQLIntegrityConstraintViolationException` is not an instance of `RuntimeException`, so cannot be passed to the built-in ex. translation utilities ... ending up with a too generic` DataAccessException`
- [x] JDO: On unique constraint violation, we get a `NucleusDataStoreException` that translates to `JDODataStoreException` that does not translate to `DataIntegrityViolationException`
- [x] DefaultJdoDialect has no `SQLExceptionTranslator` set, so relies on the JDO provider's native exception translation
- [ ] Datanucleus: On unique constraint violation, wraps a `NucleusDataStoreException` with an `IllegalArgumentException` which obscures further translation attempts
- [x] TransactionService (Isis) should not translate exceptions, there is no point, since not all transactions are gated by it
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [isis] andi-huber edited a comment on pull request #373: ISIS-2502: working on Exception Recognizers
Posted by GitBox <gi...@apache.org>.
andi-huber edited a comment on pull request #373:
URL: https://github.com/apache/isis/pull/373#issuecomment-775657475
- [x] JPA: `SQLIntegrityConstraintViolationException` is not an instance of `RuntimeException`, so cannot be passed to the built-in ex. translation utilities ... ending up with a too generic` DataAccessException`
- [x] JDO: On unique constraint violation, we get a `NucleusDataStoreException` that translates to `JDODataStoreException` that does not translate to `DataIntegrityViolationException`
- [x] DefaultJdoDialect has no `SQLExceptionTranslator` set, so relies on the JDO provider's native exception translation
- [ ] Datanucleus: On unique constraint violation, wraps a `NucleusDataStoreException` with an `IllegalArgumentException` which obscures further translation attempts
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [isis] andi-huber edited a comment on pull request #373: ISIS-2502: working on Exception Recognizers
Posted by GitBox <gi...@apache.org>.
andi-huber edited a comment on pull request #373:
URL: https://github.com/apache/isis/pull/373#issuecomment-775657475
- [x] JPA: `SQLIntegrityConstraintViolationException` is not an instance of `RuntimeException`, so cannot be passed to the built-in ex. translation utilities ... ending up with a too generic` DataAccessException`
- [x] JDO: On unique constraint violation, we get a `NucleusDataStoreException` that translates to `JDODataStoreException` that does not translate to `DataIntegrityViolationException`
- [x] DefaultJdoDialect has no `SQLExceptionTranslator` set, so relies on the JDO provider's native exception translation
- [x] Datanucleus: On unique constraint violation, wraps a `NucleusDataStoreException` with an `IllegalArgumentException` which obscures further translation attempts
- [ ] Find the right place where to put the ex. translation logic (that is, translate anything we catch to _Spring's_ `DataAccessException` hierarchy). Could give the `TransactionService` a second change. At least any (Apache Isis) _Interaction_ should make its calls to the persistence layer through the `TransactionService`. This should even hold if within an _Action_ user code is executed that uses _Transactional Spring Proxies_ under the hood that bypass any Apache Isis logic, but we should be able to intercept exceptions at the outer most `TransactionService.callTransactional(callable)` call, even if just participating in an already existing transaction.
- [ ] But then don't let `EntityFacet`(s) do any of the ex. translation stuff, just propagate exceptions as they are.
- [x] Spring's JPA integration, on _unique constraint violation_ throws an Exception only when the Spring managed transaction gets committed, which properly propagates through the `JpaDialect` for translation. However, with Spring's JDO integration, the Exception is thrown before the Spring managed transaction gets committed, which later does not propagate through the `JdoDialect` for translation. This breaks symmetry and makes it hard to reason on where to put the exception interception logic, that does the translation.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [isis] andi-huber edited a comment on pull request #373: ISIS-2502: working on Exception Recognizers
Posted by GitBox <gi...@apache.org>.
andi-huber edited a comment on pull request #373:
URL: https://github.com/apache/isis/pull/373#issuecomment-775657475
- [x] JPA: `SQLIntegrityConstraintViolationException` is not an instance of `RuntimeException`, so cannot be passed to the built-in ex. translation utilities ... ending up with a too generic` DataAccessException`
- [ ] JDO: On unique constraint violation, we get a `NucleusDataStoreException` that translates to `JDODataStoreException` that does not translate to `DataIntegrityViolationException`
- [ ] DefaultJdoDialect has no `SQLExceptionTranslator` set, so relies on the JDO provider's native exception translation
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [isis] andi-huber edited a comment on pull request #373: ISIS-2502: working on Exception Recognizers
Posted by GitBox <gi...@apache.org>.
andi-huber edited a comment on pull request #373:
URL: https://github.com/apache/isis/pull/373#issuecomment-775657475
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [isis] andi-huber edited a comment on pull request #373: ISIS-2502: working on Exception Recognizers
Posted by GitBox <gi...@apache.org>.
andi-huber edited a comment on pull request #373:
URL: https://github.com/apache/isis/pull/373#issuecomment-775657475
- [x] JPA: `SQLIntegrityConstraintViolationException` is not an instance of `RuntimeException`, so cannot be passed to the built-in ex. translation utilities ... ending up with a too generic` DataAccessException`
- [x] JDO: On unique constraint violation, we get a `NucleusDataStoreException` that translates to `JDODataStoreException` that does not translate to `DataIntegrityViolationException`
- [x] DefaultJdoDialect has no `SQLExceptionTranslator` set, so relies on the JDO provider's native exception translation
- [x] Datanucleus: On unique constraint violation, wraps a `NucleusDataStoreException` with an `IllegalArgumentException` which obscures further translation attempts
- [x] Find the right place where to put the ex. translation logic (that is, translate anything we catch to _Spring's_ `DataAccessException` hierarchy). Could give the `TransactionService` a second change. At least any (Apache Isis) _Interaction_ should make its calls to the persistence layer through the `TransactionService`. This should even hold if within an _Action_ user code is executed that uses _Transactional Spring Proxies_ under the hood that bypass any Apache Isis logic, but we should be able to intercept exceptions at the outer most `TransactionService.callTransactional(callable)` call, even if just participating in an already existing transaction.
- [ ] But then don't let `EntityFacet`(s) do any of the ex. translation stuff, just propagate exceptions as they are.
- [x] Spring's JPA integration, on _unique constraint violation_ throws an Exception only when the Spring managed transaction gets committed, which properly propagates through the `JpaDialect` for translation. However, with Spring's JDO integration, the Exception is thrown before the Spring managed transaction gets committed, which later does not propagate through the `JdoDialect` for translation. This breaks symmetry and makes it hard to reason on where to put the exception interception logic, that does the translation.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [isis] andi-huber edited a comment on pull request #373: ISIS-2502: working on Exception Recognizers
Posted by GitBox <gi...@apache.org>.
andi-huber edited a comment on pull request #373:
URL: https://github.com/apache/isis/pull/373#issuecomment-775657475
- [x] JPA: `SQLIntegrityConstraintViolationException` is not an instance of `RuntimeException`, so cannot be passed to the built-in ex. translation utilities ... ending up with a too generic` DataAccessException`
- [x] JDO: On unique constraint violation, we get a `NucleusDataStoreException` that translates to `JDODataStoreException` that does not translate to `DataIntegrityViolationException`
- [x] DefaultJdoDialect has no `SQLExceptionTranslator` set, so relies on the JDO provider's native exception translation
- [x] Datanucleus: On unique constraint violation, wraps a `NucleusDataStoreException` with an `IllegalArgumentException` which obscures further translation attempts
- [ ] Find the right place where to put the ex. translation logic (that is, translate anything we catch to _Spring's_ `DataAccessException` hierarchy). Could give the `TransactionService` a second change. At least any (Apache Isis) _Interaction_ should make its calls to the persistence layer through the `TransactionService`. This should even hold if within an _Action_ user code is executed that uses _Transactional Spring Proxies_ under the hood that bypass any Apache Isis logic, but we should be able to intercept exceptions at the outer most `TransactionService.callTransactional(callable)` call, even if just participating in an already existing transaction.
- [ ] But then don't let `EntityFacet`(s) do any of the ex. translation stuff, just propagate exceptions as they are.
- [ ] Spring's JPA integration, on _unique constraint violation_ throws an Exception only when the Spring managed transaction gets committed, which properly propagates through the `JpaDialect` for translation. However, with Spring's JDO integration, the Exception is thrown before the Spring managed transaction gets committed, which later does not propagate through the `JdoDialect` for translation. This breaks symmetry and makes it hard to reason on where to put the exception interception logic, that does the translation.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [isis] andi-huber merged pull request #373: ISIS-2502: working on Exception Recognizers
Posted by GitBox <gi...@apache.org>.
andi-huber merged pull request #373:
URL: https://github.com/apache/isis/pull/373
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [isis] andi-huber edited a comment on pull request #373: ISIS-2502: working on Exception Recognizers
Posted by GitBox <gi...@apache.org>.
andi-huber edited a comment on pull request #373:
URL: https://github.com/apache/isis/pull/373#issuecomment-775657475
- [x] JPA: `SQLIntegrityConstraintViolationException` is not an instance of `RuntimeException`, so cannot be passed to the built-in ex. translation utilities ... ending up with a too generic` DataAccessException`
- [x] JDO: On unique constraint violation, we get a `NucleusDataStoreException` that translates to `JDODataStoreException` that does not translate to `DataIntegrityViolationException`
- [x] DefaultJdoDialect has no `SQLExceptionTranslator` set, so relies on the JDO provider's native exception translation
- [ ] Datanucleus: On unique constraint violation, wraps a `NucleusDataStoreException` with an `IllegalArgumentException` which obscures further translation attempts
- [ ] Find the right place where to put the ex. translation logic (that is, translate anything we catch to _Spring's_ `DataAccessException` hierarchy). Could give the `TransactionService` a second change. At least any (Apache Isis) _Interaction_ should make its calls to the persistence layer through the `TransactionService`. This should even hold if within an _Action_ user code is executed that uses _Transactional Spring Proxies_ under the hood that bypass any Apache Isis logic, but we should be able to intercept exceptions at the outer most `TransactionService.callTransactional(callable)` call, even if just participating in an already existing transaction.
- [ ] But then don't let `EntityFacet`(s) do any of the ex. translation stuff, just propagate exceptions as they are.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [isis] andi-huber edited a comment on pull request #373: ISIS-2502: working on Exception Recognizers
Posted by GitBox <gi...@apache.org>.
andi-huber edited a comment on pull request #373:
URL: https://github.com/apache/isis/pull/373#issuecomment-775657475
- [x] JPA: `SQLIntegrityConstraintViolationException` is not an instance of `RuntimeException`, so cannot be passed to the built-in ex. translation utilities ... ending up with a too generic` DataAccessException`
- [x] JDO: On unique constraint violation, we get a `NucleusDataStoreException` that translates to `JDODataStoreException` that does not translate to `DataIntegrityViolationException`
- [x] DefaultJdoDialect has no `SQLExceptionTranslator` set, so relies on the JDO provider's native exception translation
- [ ] Datanucleus: On unique constraint violation, wraps a `NucleusDataStoreException` with an `IllegalArgumentException` which obscures further translation attempts
- [ ] Find the right place where to put the ex. translation logic (that is, translate anything we catch to _Spring's_ `DataAccessException` hierarchy). Could give the `TransactionService` a second change. At least any (Apache Isis) _Interaction_ should make its calls to the persistence layer through the `TransactionService`. This should even hold if within an _Action_ user code is executed that uses _Transactional Spring Proxies_ under the hood that bypass any Apache Isis logic, but we should be able to intercept exceptions at the outer most `TransactionService.callTransactional(callable)` call, even if just participating in an already existing transaction.
- [ ] But then don't let `EntityFacet`(s) do any of the ex. translation stuff, just propagate exceptions as they are.
- [ ] Spring's JPA integration, on _unique constraint violation_ throws an Exception only when the Spring managed transaction gets committed, which properly propagates through the `JpaDialect` for translation. However, with Spring's JDO integration, the Exception is thrown before the Spring managed transaction gets committed, which later does not propagate through the `JdoDialect` for translation. This breaks symmetry and makes it hard to reason on where to put the exception interception logic, that does the translation.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org