Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.2.0-BETA1
    • Fix Version/s: None
    • Component/s: Record
    • Labels:
      None
    • Environment:
      Doctrine Version: 1.2.0-BETA1 on Symfony 1.3 - BETA
      pdo_dblib / MsSQL
      Linux

      Description

      sfDoctrineRecord.class.php incorrectly attempts to parse dates from the MsSQL datetime field.

      MsSQL dates return in the following format:

      Oct 12 2009 12:16:22:000AM

        Activity

        Hide
        Jonathan H. Wage added a comment -

        I don't understand your issue. Can you provide some more information?

        Show
        Jonathan H. Wage added a comment - I don't understand your issue. Can you provide some more information?
        Hide
        Trevor Lanyon added a comment -

        After reviewing this might be a Symfony issue and not a doctrine issue as the problem is with this class. I'll explain this better in case:

        lib/plugins/sfDoctrinePlugin/lib/record/sfDoctrineRecord.class.php

        It has this method:

        public function getDateTimeObject($dateFieldName)
        {
        $type = $this->getTable()->getTypeOf($dateFieldName);
        if ($type == 'date' || $type == 'timestamp')

        { return new DateTime($this->get($dateFieldName)); }

        else

        { throw new sfException('Cannot call getDateTimeObject() on a field that is not of type date or timestamp.'); }

        }

        Microsoft SQL server returns TIMESTAMPS in a ridiculous format like this "Nov 16 2009 12:08:44:000AM" so this method breaks. Easy fix but a bug nonetheless.

        Again, this doesn't belong here does it, it's a symfony thing?

        Show
        Trevor Lanyon added a comment - After reviewing this might be a Symfony issue and not a doctrine issue as the problem is with this class. I'll explain this better in case: lib/plugins/sfDoctrinePlugin/lib/record/sfDoctrineRecord.class.php It has this method: public function getDateTimeObject($dateFieldName) { $type = $this->getTable()->getTypeOf($dateFieldName); if ($type == 'date' || $type == 'timestamp') { return new DateTime($this->get($dateFieldName)); } else { throw new sfException('Cannot call getDateTimeObject() on a field that is not of type date or timestamp.'); } } Microsoft SQL server returns TIMESTAMPS in a ridiculous format like this "Nov 16 2009 12:08:44:000AM" so this method breaks. Easy fix but a bug nonetheless. Again, this doesn't belong here does it, it's a symfony thing?
        Hide
        Jonathan H. Wage added a comment -

        I don't think this is something that can be "fixed". the DateTime object uses strtotime() and is mssql provides a date it doesn't understand, we can't do much about it. I think you need to configure your mssql server to return a date format that php can parse properly.

        Show
        Jonathan H. Wage added a comment - I don't think this is something that can be "fixed". the DateTime object uses strtotime() and is mssql provides a date it doesn't understand, we can't do much about it. I think you need to configure your mssql server to return a date format that php can parse properly.
        Hide
        Trevor Lanyon added a comment -

        I don't want to be working with Mssql (who would?). I can't change the database or the configuration of the database, other systems rely on the stuff.

        There are some serious problems with trying to use Doctrine with MsSQL. PDO for mssql (pdo_dblib) doesn't let you indicate columns more then 30 characters. With the aliasing of columns scheme some columns in my tables go over that and Doctrine thinks it needs to hydrate all of the objects I return because it sees a null (pragmatic: I didn't trace the code to find that, only trial and error). And now it looks like I'll have to keep the modification I made to the code to work with dates (which means I will without exception run into further problems) .

        I suppose I'll have to crawl back to my propel code base. With the no real composite key support and no interest in supporting MsSQL I'll have a hard time explaining the choice to anyone else in my group.

        Awesome tool if I'm building something out of the box and I can design the environment for it's needs. Too many problems if you have to wrap it around something existing. Good luck! I look forward to future releases. Thank you for your responses!

        Show
        Trevor Lanyon added a comment - I don't want to be working with Mssql (who would?). I can't change the database or the configuration of the database, other systems rely on the stuff. There are some serious problems with trying to use Doctrine with MsSQL. PDO for mssql (pdo_dblib) doesn't let you indicate columns more then 30 characters. With the aliasing of columns scheme some columns in my tables go over that and Doctrine thinks it needs to hydrate all of the objects I return because it sees a null (pragmatic: I didn't trace the code to find that, only trial and error). And now it looks like I'll have to keep the modification I made to the code to work with dates (which means I will without exception run into further problems) . I suppose I'll have to crawl back to my propel code base. With the no real composite key support and no interest in supporting MsSQL I'll have a hard time explaining the choice to anyone else in my group. Awesome tool if I'm building something out of the box and I can design the environment for it's needs. Too many problems if you have to wrap it around something existing. Good luck! I look forward to future releases. Thank you for your responses!
        Hide
        Jonathan H. Wage added a comment -

        I'm open to any suggestions to fix the issue. Before we can really say mssql works well in Doctrine, we'll really need to thoroughly test it against a mssql server. Currently none of us have one.

        Show
        Jonathan H. Wage added a comment - I'm open to any suggestions to fix the issue. Before we can really say mssql works well in Doctrine, we'll really need to thoroughly test it against a mssql server. Currently none of us have one.
        Hide
        Trevor Lanyon added a comment - - edited

        In the newest version of Symfony, Doctrine (and php 5.3.x) this is no longer a problem.

        There is a new problem now (http://trac.symfony-project.org/ticket/7676) but I thought i was probably more a symfony problem.

        I'm not ready to throw the towel in just yet.

        In response to your need for a mssql server: I have a clustered environment that I have to work with. If I can do any testing please let me know. I would very much like to contribute to Doctrine's success.

        Thank you for your help.

        Show
        Trevor Lanyon added a comment - - edited In the newest version of Symfony, Doctrine (and php 5.3.x) this is no longer a problem. There is a new problem now ( http://trac.symfony-project.org/ticket/7676 ) but I thought i was probably more a symfony problem. I'm not ready to throw the towel in just yet. In response to your need for a mssql server: I have a clustered environment that I have to work with. If I can do any testing please let me know. I would very much like to contribute to Doctrine's success. Thank you for your help.

          People

          • Assignee:
            Jonathan H. Wage
            Reporter:
            Trevor Lanyon
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: