Doctrine 1
  1. Doctrine 1
  2. DC-713

[pgsql] importer does not fetch varchar max length

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2.2
    • Fix Version/s: None
    • Component/s: Import/Export
    • Labels:
      None
    • Environment:
      PostgreSql

      Description

      The importer doe not look for the max length of string columns.

      For example, the task generate-models-db is generating definitions like
      $this->hasColumn('code', 'string', null, array(/**/));

      instead of
      $this->hasColumn('code', 'string', 10, array(/**/));

        Activity

        Hide
        Jonathan H. Wage added a comment -

        Can you generate a patch and paste it in a code block?

        Show
        Jonathan H. Wage added a comment - Can you generate a patch and paste it in a code block?
        Hide
        Jonathan H. Wage added a comment -

        Hopefully this fixes it for good.

        http://trac.doctrine-project.org/changeset/7689

        Show
        Jonathan H. Wage added a comment - Hopefully this fixes it for good. http://trac.doctrine-project.org/changeset/7689
        Hide
        Francesco Montefoschi added a comment -

        It seems to be fine!

        Show
        Francesco Montefoschi added a comment - It seems to be fine!
        Hide
        Miha Vrhovnik added a comment - - edited

        Ok.. this is complete mess, somebody with permissions should reopen it.
        This one works for Francesco as he is running with notices disabled.
        if ttype is removed or commented out , then you get a notices that ttype key doesn't exist.
        and it seems that ttype is required for enums to work.

        in one of the comments Ricardo suggested replacing ...
        t.typtype AS typtype with
        (SELECT t.typtype FROM pg_type t WHERE t.typname = udt_name) AS typtype,

        adding this get's rid of notices, but i don't know what happens for other things mentioned within comments of if this is a correct fix... The one who provided support for enums should take a look

        I think Francesco should run import with notices enabled and then add the upper sub-query to get rid f them.. then it should also test if the rest of the import still works correctly.

        Show
        Miha Vrhovnik added a comment - - edited Ok.. this is complete mess, somebody with permissions should reopen it. This one works for Francesco as he is running with notices disabled. if ttype is removed or commented out , then you get a notices that ttype key doesn't exist. and it seems that ttype is required for enums to work. in one of the comments Ricardo suggested replacing ... t.typtype AS typtype with (SELECT t.typtype FROM pg_type t WHERE t.typname = udt_name) AS typtype, adding this get's rid of notices, but i don't know what happens for other things mentioned within comments of if this is a correct fix... The one who provided support for enums should take a look I think Francesco should run import with notices enabled and then add the upper sub-query to get rid f them.. then it should also test if the rest of the import still works correctly.
        Hide
        Francesco Montefoschi added a comment -

        My apologies, I developed the patch on a non development machine, so I used the default PHP configuration.

        Show
        Francesco Montefoschi added a comment - My apologies, I developed the patch on a non development machine, so I used the default PHP configuration.

          People

          • Assignee:
            Jonathan H. Wage
            Reporter:
            Francesco Montefoschi
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: