database Type of Char converted to System.String

[GoogleCodeExporter]

When I am generating my CSLA template it is generating properties that are 
"Char" in the database as String.  This is a problem since my Data Layer has 
the properties defined as System.Char and it can't convert the two on the fly.

From what I can tell in the template in the Properties.cst file it's using 
member.SystemType.  To clarify these are just a single Char field not an array 
of Char.  They can be null or not null both have the problem.

I am using Codesmith 6 with the most recent templates.

Thanks

David Logan

Original issue reported on code.google.com by ibflyfis...@yahoo.com on 13 Feb 2012 at 6:18

[GoogleCodeExporter]

Original comment by bniemyjski on 14 Feb 2012 at 7:18

• Changed state: Accepted
• Added labels: Type-Defect, Framework-CSLA

[GoogleCodeExporter]

This issue was updated by revision r2507.

Fixed a bug where database Type of Char converted to System.String

Original comment by bniemyjski on 8 Mar 2012 at 8:29

[GoogleCodeExporter]

Original comment by bniemyjski on 8 Mar 2012 at 8:30

• Changed state: Fixed

[GoogleCodeExporter]

After further consideration, this is something we are going to revert. Almost 
all other frameworks treat char as a string for ease of use. For example if you 
want to pass in an empty string to a char field its a bit difficult or using 
char as a middle initial and doing string manipulations.

Please see this for more information: 
http://www.jeremycade.com/2010/06/a-wtf-moment-with-entity-framework-4-0/

Original comment by bniemyjski on 8 Mar 2012 at 9:37

• Changed state: WontFix

[GoogleCodeExporter]

Then wouldn't it make sense to have the PLINQO-NH templates generate the 
properties as Strings?  The problem I'm having is somewhere there has to be a 
conversion that happens and right now I'm faced with changing all the CSLA or 
all the NHibernate properties to one or the other.

Original comment by ibflyfis...@yahoo.com on 20 Mar 2012 at 8:51

[GoogleCodeExporter]

Hello,

They both should be generating as strings. If this is not the case, please let 
me know.

Original comment by bniemyjski on 20 Mar 2012 at 9:28

[GoogleCodeExporter]

this is code from one of the entities in my most recent build using yesterday's 
release of the generator:

        [System.CodeDom.Compiler.GeneratedCode("CodeSmith", "6.0.0.0")]
        private System.Char _sprocessinggroup;

        [System.Runtime.Serialization.DataMember(Order = 4)]
        [System.CodeDom.Compiler.GeneratedCode("CodeSmith", "6.0.0.0")]
        public virtual System.Char Sprocessinggroup
        {
            get { return _sprocessinggroup; }
            set
            {
                OnSprocessinggroupChanging(value, _sprocessinggroup);
                SendPropertyChanging("Sprocessinggroup");
                _sprocessinggroup = value;
                SendPropertyChanged("Sprocessinggroup");
                OnSprocessinggroupChanged(value);
            }
        }

Original comment by ibflyfis...@yahoo.com on 21 Mar 2012 at 4:57

[GoogleCodeExporter]

Thanks,

I'll take a look into this.

Original comment by bniemyjski on 28 Mar 2012 at 3:56

[GoogleCodeExporter]

Blake,

I'm curious if you have built a sql server LinqToSql project on a database that 
has any "Char" fields.  LinqToSql also generates them as "Char" properties and 
you get conversion errors when you go to compile the project.  My guess is, if 
you are not going to carry the "Char" through to the CSLA Templates you will 
need to add logic to the templates that "convert" the Char to String.

I'm curious to see what you do.  I am debating on changing all the HBM files in 
my PLINQO project to "Strings" with length of 1 or adding the conversion code.  
I haven't decided which will be the better way.

Original comment by ibflyfis...@yahoo.com on 3 Apr 2012 at 4:39

[GoogleCodeExporter]

Original comment by bniemyjski on 4 Apr 2012 at 6:13

• Changed state: Investigating

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hello,

I finally got time to look into this :(. I am using the following script:

CREATE TABLE [dbo].[StringTypes](
    [nvarchar1] [nvarchar](1) NOT NULL,
    [varchar1] [varchar](1) NOT NULL,
    [char1] [char](1) NULL,
    [char10] [char](10) NULL,
    [nchar1] [nchar](1) NULL,
    [nchar10] [nchar](10) NULL,
    [text] [text] NULL,
    [ntext] [ntext] NULL,
 CONSTRAINT [PK_StringTypes] PRIMARY KEY CLUSTERED 
(
    [nvarchar1] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, 
ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

SET ANSI_PADDING OFF
GO

I did verify that CSLA and PLINQO for Linq-to-sql both generate strings for all 
of these types, but the nhibernate templates generate a char for nchar(1) and 
char(1).

PLINQO does compile and run and allow you to insert records into this table. It 
also generates dataannotations for string length 
([System.ComponentModel.DataAnnotations.StringLength(1)]) to limit the size of 
string you can enter.

I'll take a look into whats needed to get the nhibernate templates to generate 
a string.

Original comment by bniemyjski on 5 Apr 2012 at 10:07

[GoogleCodeExporter]

Would you be willing to test this for us in nHibernate.

You would need to open the source project and modify the 
NHibernateCommandProperty InitializeMethod's call into 
NHibernateUtilities.FromNHibernateType(string, int?).

You would just need to comment out the char check and recompile / regenerate.

Original comment by bniemyjski on 5 Apr 2012 at 10:13

• Changed state: AwaitingInfo

[GoogleCodeExporter]

Original comment by bniemyjski on 5 Apr 2012 at 10:13

• Added labels: Framework-NHibernate
• Removed labels: Framework-CSLA

[GoogleCodeExporter]

yeah I can test.  Let me take you table defs and run some test with them first 
because that wasn't the behavior I saw with LinkToSql.

Original comment by ibflyfis...@yahoo.com on 6 Apr 2012 at 2:56

[GoogleCodeExporter]

Sounds good, please let me know what you find.

Original comment by bniemyjski on 6 Apr 2012 at 4:31