mirror of
https://github.com/doctrine/orm.git
synced 2026-03-24 06:52:09 +01:00
DDC-2807: Add support for char fields in the ORM layer #340
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @doctrinebot on GitHub (Jan 24, 2010).
Jira issue originally created by user darkangel:
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")
@doctrinebot commented on GitHub (Jan 24, 2010):
Comment created by romanb:
I dont think this is worth including in the main distribution. A char does not save much compared to a varchar (1 Byte?) and you already have 2 options to make a char:
IMHO, just use a string type with the length you want: @Column(type="string", length=2). That becomes a varchar with length 2.
@doctrinebot commented on GitHub (Jan 24, 2010):
Comment created by darkangel:
Ya, it is only 1 extra byte. I'm not sure what to do, I like things as optimized as possible, but I guess I could just use columnDefinition if necessary.
@doctrinebot commented on GitHub (Jan 24, 2010):
Comment created by darkangel:
Actually, I don't really see any reason not to include the char type.
@doctrinebot commented on GitHub (Jan 24, 2010):
Comment created by romanb:
How about code bloat? :)
@doctrinebot commented on GitHub (Jan 24, 2010):
Comment created by darkangel:
How many LoC?
@doctrinebot commented on GitHub (Jan 25, 2010):
Comment created by @guilhermeblanco:
@darkangel Around 40. And lots of conditionals, which decreases efficiency of algorithm.
I vote for FixedString DBAL DataType.
@doctrinebot commented on GitHub (Jan 25, 2010):
Comment created by romanb:
We will not put every special data type someone comes up with in the core library. If we go this route, at the end we have 100 data types (100 classes plus a bloated type map) in the core library.
There are at least 2 decent options of making a char already if you care about byte counting (see above).
"Why not?" is not the question to ask for when it comes to new features. If it were, we would include a whole lot of stuff that is useless for 99% of the users. There must be strong arguments for "Why?" and there are none.
If we get 50+ votes on this issue we can talk again.
@doctrinebot commented on GitHub (Jan 25, 2010):
Comment created by darkangel:
Of course not. I didn't know that char was a special data type (especially since it's supported in DC1.2).
I will use @columnDefinition.
You may close this issue.
@doctrinebot commented on GitHub (Jan 25, 2010):
Comment created by romanb:
No need to become defensive. There is still the chance that demand for this particular type gets very high and that can change things.
Thats why this stays open. Otherwise the next guy would probably just create a duplicate ticket (not sure whether non-owners can reopen other tickets).
@doctrinebot commented on GitHub (Jan 25, 2010):
Comment created by @beberlei:
@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.
@doctrinebot commented on GitHub (Jan 25, 2010):
Comment created by darkangel:
@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.
@doctrinebot commented on GitHub (Sep 17, 2011):
Comment created by strygin:
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.
@doctrinebot commented on GitHub (Jun 24, 2013):
Comment created by @deeky666:
As Dmitry stated, this is fixed by the "fixed" property. Shouldn't this be closed?
@doctrinebot commented on GitHub (Nov 21, 2013):
Comment created by @deeky666:
Fixed in 2.4.0:
cfee331006You can pass column options:
This generates a CHAR instead of VARCHAR column.
@doctrinebot commented on GitHub (Nov 21, 2013):
Issue was closed with resolution "Fixed"