Doctrine 2 - ORM
  1. Doctrine 2 - ORM
  2. DDC-2807

Add support for char fields in the ORM layer

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.1, 2.1.1, 2.1.2
    • Fix Version/s: 2.4
    • Component/s: None
    • Security Level: All
    • Labels:
      None

      Description

      It's not possible to use char fields in the ORM layer.

      It should be possible to use something like:

      @Column(type="char") or ...
      @Column(type="string", fixed=true) or ...
      @Column(type="fixedstring")

        Activity

        Hide
        Steve Müller added a comment - - edited

        Fixed in 2.4.0:

        https://github.com/doctrine/doctrine2/commit/cfee331006c0011ca09250bb7ba4e07c32bb68ad

        You can pass column options:

        @Column(type="string", options={"fixed" = true})
        

        This generates a CHAR instead of VARCHAR column.

        Show
        Steve Müller added a comment - - edited Fixed in 2.4.0: https://github.com/doctrine/doctrine2/commit/cfee331006c0011ca09250bb7ba4e07c32bb68ad You can pass column options: @Column(type="string", options={"fixed" = true}) This generates a CHAR instead of VARCHAR column.
        Hide
        Steve Müller added a comment -

        As Dmitry stated, this is fixed by the "fixed" property. Shouldn't this be closed?

        Show
        Steve Müller added a comment - As Dmitry stated, this is fixed by the "fixed" property. Shouldn't this be closed?
        Hide
        Dmitry Strygin added a comment -

        Sorry for party rocking but i think that 'fixed' annotation should be enabled in ORM column definitions.
        In this case @Column(type="string", length=4, fixed=true) would result in "CHAR(4)" for MySQL, Oracle and Postgres, Sqlite, and DB2, "NCHAR(4)" for MQSQL. etc... It is much more elegant than that columnDefinition.
        It is already supported by DBAL as well as 'default' heartlessly removed (DDC-100) from annotation driver due to bizzare reluctance to deal with proper escaping of values.

        Show
        Dmitry Strygin added a comment - Sorry for party rocking but i think that 'fixed' annotation should be enabled in ORM column definitions. In this case @Column(type="string", length=4, fixed=true) would result in "CHAR(4)" for MySQL, Oracle and Postgres, Sqlite, and DB2, "NCHAR(4)" for MQSQL. etc... It is much more elegant than that columnDefinition . It is already supported by DBAL as well as 'default' heartlessly removed ( DDC-100 ) from annotation driver due to bizzare reluctance to deal with proper escaping of values.
        Hide
        Glen Ainscow added a comment -

        @Roman
        Not being defensive, I have accepted/respected your decision.

        @Benamin
        I did think about cross-database compatibility. As far as I know, char is supported by the vast majority (or at least easily simulated). But I understand.

        Thanks.

        Show
        Glen Ainscow added a comment - @Roman Not being defensive, I have accepted/respected your decision. @Benamin I did think about cross-database compatibility. As far as I know, char is supported by the vast majority (or at least easily simulated). But I understand. Thanks.
        Hide
        Benjamin Eberlei added a comment -

        @Glen

        The problem with Doctrine 1 and having lots of different data-types is that of maintainability. You have to ensure that all the types work on all supported platforms with each and every version. The more datatypes we support by default the more complex will it be for the Doctrine 2 Core to ensure compability and maintainability in this regard.

        For each new platform that we will support all datatypes have to be supported for example, something that might even become impossible for some databases.

        Adding a datatype from the user perspective is rather simple though, it has to be tested once and is only about 20-40 LOC. I bet you 100 bucks that soon there will be code-snippets out there on all the different database specific types as a doctrine 2 implemention.

        Show
        Benjamin Eberlei added a comment - @Glen The problem with Doctrine 1 and having lots of different data-types is that of maintainability. You have to ensure that all the types work on all supported platforms with each and every version. The more datatypes we support by default the more complex will it be for the Doctrine 2 Core to ensure compability and maintainability in this regard. For each new platform that we will support all datatypes have to be supported for example, something that might even become impossible for some databases. Adding a datatype from the user perspective is rather simple though, it has to be tested once and is only about 20-40 LOC. I bet you 100 bucks that soon there will be code-snippets out there on all the different database specific types as a doctrine 2 implemention.

          People

          • Assignee:
            Roman S. Borschel
            Reporter:
            Glen Ainscow
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: