Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.2 branch
    • Fix Version/s: None
    • Component/s: Core Library
    • Labels:
      None

      Description

      [Supporting Arbitrary PK types at the Generator Level]

      We need to support at least "long" in addition to "int". I guess the good idea is to generalize this and only use "Object" in the API. Another idea is to change generator method signiture to take DbAttribute instead of DbEntity, as this will provide a way to determine the type of the key.

      [Bootstrapping PK Generator]

      void createAutoPk(DataNode node, List dbEntities);

      with

      void createAutoPk(
      DataNode node,
      List dbEntities,
      int defaultStartValue,
      boolean checkCurrentValues);

      But this will only work if DbGenerator uses DataNode instead of raw SQL connection. Another problem is that PkGenerator has a number of methods that simply return SQL code without running it. This is useful for showing the users what will be executed (and also allows users to store the script and run it later), however it limits the possibilities for encapsulation of PK logic. ...

      I guess we'll have to stick with providing a SQL solution that can be executed outside of Cayenne (e.g. PL/SQL for Oracle). Don't see a way around it. However sql-generation methods of PkGenerator (and eventually DbAdapter) can be deprecated. Instead we should implement PKGenerators via SQLTemplates. Then we can run such SQLTemplate in two modes - "normal" for actual generation and "mock" for text SQL script output. This may depend on CAY-304 feature.

      This should provide new capabilities and make DbAdapter/PKGenerator API simpler and much more consistent.

        Issue Links

          Activity

          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Closed Closed
          2730d 11h 45m 1 Andrus Adamchik 28/Oct/12 15:41
          Andrus Adamchik made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Fix Version/s Short term future [ 12313762 ]
          Resolution Won't Fix [ 2 ]
          Hide
          Andrus Adamchik added a comment -

          we need something DI-based for PkGenerator customization... this will require a separate issue though.

          Show
          Andrus Adamchik added a comment - we need something DI-based for PkGenerator customization... this will require a separate issue though.
          Ari Maniatis made changes -
          Issue Type New Feature [ 2 ] Improvement [ 4 ]
          Ari Maniatis made changes -
          Workflow jira [ 12456974 ] Cayenne workflow [ 12487615 ]
          Henri Yandell made changes -
          Project Import Sat Mar 21 00:51:04 PDT 2009 [ 1237621864637 ]
          Ari Maniatis made changes -
          Fix Version/s Short term future [ 10125 ]
          Fix Version/s 3.0 [ 10091 ]
          Hide
          Kevin Menard added a comment -

          I don't know how generic you want this, but you could use Number and let auto-boxing do the trick.

          Show
          Kevin Menard added a comment - I don't know how generic you want this, but you could use Number and let auto-boxing do the trick.
          Andrus Adamchik made changes -
          Fix Version/s UNDEFINED FUTURE [ 10031 ]
          Fix Version/s 3.0 [ 10091 ]
          Hide
          Andrus Adamchik added a comment -

          first part of it (Long PK) is needed for JPA

          Show
          Andrus Adamchik added a comment - first part of it (Long PK) is needed for JPA
          Andrus Adamchik made changes -
          Link This issue is referenced by CAY-329 [ CAY-329 ]
          Andrus Adamchik made changes -
          Fix Version/s 1.2 [DEV] [ 10030 ]
          Fix Version/s AFTER 1.2 [ 10031 ]
          Hide
          Andrus Adamchik added a comment -

          Or better syntax for handling empty tables:

          select setval('pk_my_table', coalesce(max(id) + 1, 200)) from my_table

          Show
          Andrus Adamchik added a comment - Or better syntax for handling empty tables: select setval('pk_my_table', coalesce(max(id) + 1, 200)) from my_table
          Hide
          Andrus Adamchik added a comment -

          A note on setting correct sequence value. On PostgreSQL the syntax looks like this:

          select setval('pk_my_table', max(pk_column) + 1) from my_table

          Show
          Andrus Adamchik added a comment - A note on setting correct sequence value. On PostgreSQL the syntax looks like this: select setval('pk_my_table', max(pk_column) + 1) from my_table
          Andrus Adamchik made changes -
          Field Original Value New Value
          Description Make PK generator smarter. General idea is to replace
             
          void createAutoPk(DataNode node, List dbEntities);

          with

          void createAutoPk(
             DataNode node,
             List dbEntities,
             int defaultStartValue,
             boolean checkCurrentValues);

          But this will only work if DbGenerator uses DataNode instead of raw SQL connection. Another problem is that PkGenerator has a number of methods that simply return SQL code without running it. This is useful for showing the users what will be executed (and also allows users to store the script and run it later), however it limits the possibilities for encapsulation of PK logic. ...

          I guess we'll have to stick with providing a SQL solution that can be executed outside of Cayenne (e.g. PL/SQL for Oracle). Don't see a way around it. However sql-generation methods of PkGenerator (and eventually DbAdapter) can be deprecated. Instead we should implement PKGenerators via SQLTemplates. Then we can run such SQLTemplate in two modes - "normal" for actual generation and "mock" for text SQL script output. This may depend on CAY-304 feature.

          This should provide new capabilities and make DbAdapter/PKGenerator API simpler and much more consistent.




             
          [Supporting Arbitrary PK types at the Generator Level]

          We need to support at least "long" in addition to "int". I guess the good idea is to generalize this and only use "Object" in the API. Another idea is to change generator method signiture to take DbAttribute instead of DbEntity, as this will provide a way to determine the type of the key.


          [Bootstrapping PK Generator]
             
          void createAutoPk(DataNode node, List dbEntities);

          with

          void createAutoPk(
             DataNode node,
             List dbEntities,
             int defaultStartValue,
             boolean checkCurrentValues);

          But this will only work if DbGenerator uses DataNode instead of raw SQL connection. Another problem is that PkGenerator has a number of methods that simply return SQL code without running it. This is useful for showing the users what will be executed (and also allows users to store the script and run it later), however it limits the possibilities for encapsulation of PK logic. ...

          I guess we'll have to stick with providing a SQL solution that can be executed outside of Cayenne (e.g. PL/SQL for Oracle). Don't see a way around it. However sql-generation methods of PkGenerator (and eventually DbAdapter) can be deprecated. Instead we should implement PKGenerators via SQLTemplates. Then we can run such SQLTemplate in two modes - "normal" for actual generation and "mock" for text SQL script output. This may depend on CAY-304 feature.

          This should provide new capabilities and make DbAdapter/PKGenerator API simpler and much more consistent.




             
          Hide
          Andrus Adamchik added a comment -

          Looking at DataNode API, there is no easy way to mock its behavior for the purpose of capturing adapter-specific SQL witjout actually running it. I guess then we should "mock" the underlying JDBC layer. Implementing

          class NullDriver implements java.sql.Driver
          class NullConnection implements java.sql.Connection
          class NullStatement implements java.sql.Statement
          class NullPreparedStatement implements java.sql.PrepredStatement
          class NullCallableStatement implements java.sql.CallableStatement

          should do the trick... Of course this will only work for non-selecting queries, but as the main use would be capturing DDL, it should be enough.

          Show
          Andrus Adamchik added a comment - Looking at DataNode API, there is no easy way to mock its behavior for the purpose of capturing adapter-specific SQL witjout actually running it. I guess then we should "mock" the underlying JDBC layer. Implementing class NullDriver implements java.sql.Driver class NullConnection implements java.sql.Connection class NullStatement implements java.sql.Statement class NullPreparedStatement implements java.sql.PrepredStatement class NullCallableStatement implements java.sql.CallableStatement should do the trick... Of course this will only work for non-selecting queries, but as the main use would be capturing DDL, it should be enough.
          Andrus Adamchik created issue -

            People

            • Assignee:
              Andrus Adamchik
              Reporter:
              Andrus Adamchik
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development