Details

    • Type: Wish Wish
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0-beta1
    • Fix Version/s: 4.0
    • Component/s: Runtime
    • Labels:
      None

      Description

      Currently, there is no portable way to determine the reason of an Exception.
      E.g. if an exception occurs during saving, it could be due to a unique key violation.
      It would be nice such a Violation would result in a special subclass of TorqueException, so the reason could be determined in a way portable across databasess
      (Currently one can look at the root cause of the Torque exception and then e.g. form ysql check whether it's a MySQLIntegrityConstraintViolationException, but of course this is not portable across databases)

        Activity

        Thomas Fox created issue -
        Hide
        Thomas Fox added a comment -

        A constraint for solving this is that we do not want Torque to depend on the various driver classes.
        So a feasible way seems to be to look at the sqlState of the SQLException (this seems to be standardised a bit) and check whether the sqlState matches a certain pattern.
        This seems feasible so far (checked derby, mysql, postgresql) for constraint violations (though finding out whether the constraint is a unique key, foreign key, not null constraint is not possible in mysql) and for deadlocks.

        I'll create a possible solution and test cases and then check with other databases

        Show
        Thomas Fox added a comment - A constraint for solving this is that we do not want Torque to depend on the various driver classes. So a feasible way seems to be to look at the sqlState of the SQLException (this seems to be standardised a bit) and check whether the sqlState matches a certain pattern. This seems feasible so far (checked derby, mysql, postgresql) for constraint violations (though finding out whether the constraint is a unique key, foreign key, not null constraint is not possible in mysql) and for deadlocks. I'll create a possible solution and test cases and then check with other databases
        Clemens Hahn made changes -
        Field Original Value New Value
        Attachment torque4-generatedClasses.jpg [ 12549140 ]
        Clemens Hahn made changes -
        Attachment torque4-generatedClasses.jpg [ 12549140 ]
        Hide
        Thomas Fox added a comment -

        Deadlock detection does not work for hsqldb, I have not been able to produce a deadlock detected by hsqldb, the classical case for table-based locking(write table 1 transaction1, write table 2 in transaction 2, write teable 2 in transaction 1, write table1 in transaction 2) just waits indefinitely with no deadlock detected.
        Everything else works.

        Show
        Thomas Fox added a comment - Deadlock detection does not work for hsqldb, I have not been able to produce a deadlock detected by hsqldb, the classical case for table-based locking(write table 1 transaction1, write table 2 in transaction 2, write teable 2 in transaction 1, write table1 in transaction 2) just waits indefinitely with no deadlock detected. Everything else works.
        Thomas Fox made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Assignee Thomas Fox [ tfischer ]
        Fix Version/s 4.0-beta2 [ 12323291 ]
        Resolution Fixed [ 1 ]
        Thomas Fox made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Thomas Fox
            Reporter:
            Thomas Fox
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development