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

          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.
          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
          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 -

          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
          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.
          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.

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development