Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
created_at/updated_at inconsistencies
  • Hi all, ive used oil to generate a model for me, see below.  It did not add created_at and updated_at to the $_properties array. If I now add something to this model:

    $user = new Model_User($user);
    $user->save();

    Now both created_at and updated_at are 0 in the database. This had me stumped for quite a while.

    But if I manually add created_at and updated_at to the $_properties array, both values get set correctly. So it seems like either oil isnt creating the $_properties array correctly, or the orm code is looking for those 2 fields in the wrong place.

    Or of course, im doing something wrong?




    class Model_User extends \Orm\Model
    {
        // columns we operate on
        protected static $_properties = array(
            'username',
            'group',
            'email',
            'last_login',
            'login_hash',
            'profile_fields',
        );

        // relationship to other tables
        protected static $_has_many = array(
            'files' => array(
                'key_from'            => 'id',
                'model_to'            => 'Model_File',
                'key_to'            => 'user_id',
                'cascade_save'         => true,
                'cascade_delete'     => false,
            )
        );
       
        // table observers
        protected static $_observers = array(
                'Orm\Observer_CreatedAt' => array(
                        'events' => array('before_insert'),
                        'mysql_timestamp' => false,
                ),
                'Orm\Observer_UpdatedAt' => array(
                        'events' => array('before_save'),
                        'mysql_timestamp' => false,
                ),
        );
    }

  • I've just generated some code using scaffolding (on 1.5/develop), and everything seems to be there: properties, observers, and columns in the migration.

    What commandline did you exactly use to generate the code? And with which version of Fuel?
  • Hi Corbosman,

    Does this happen for every model that you try to create Via ORM? Or just this particular model?

    Regards,
    Badnewz.
  • Every model. Im using 1.4. Here, let me type this now:

    $ oil g model mymodel mycolumn:string
        Creating model: /var/www/fuel/app/classes/model/mymodel.php
        Creating migration: /var/www/fuel/app/migrations/003_create_mymodels.php

    $ cat fuel/app/classes/model/mymodel.php
    <?php

    class Model_Mymodel extends \Orm\Model
    {
        protected static $_properties = array(
            'id',
            'mycolumn'
        );

        protected static $_observers = array(
            'Orm\Observer_CreatedAt' => array(
                'events' => array('before_insert'),
                'mysql_timestamp' => false,
            ),
            'Orm\Observer_UpdatedAt' => array(
                'events' => array('before_save'),
                'mysql_timestamp' => false,
            ),
        );
    }

    cat fuel/app/migrations/003_create_mymodels.php
    <?php

    namespace Fuel\Migrations;

    class Create_mymodels
    {
        public function up()
        {
            \DBUtil::create_table('mymodels', array(
                'id' => array('constraint' => 11, 'type' => 'int', 'auto_increment' => true),
                'mycolumn' => array('constraint' => 255, 'type' => 'varchar'),
                'created_at' => array('constraint' => 11, 'type' => 'int'),
                'updated_at' => array('constraint' => 11, 'type' => 'int'),

            ), array('id'));
        }

        public function down()
        {
            \DBUtil::drop_table('mymodels');
        }

    $ oil refine migrate
    Performed migrations for app:default:
    003_create_mymodels

    $ oil console
    Fuel 1.5-dev - PHP 5.3.3-7+squeeze14 (cli) (Aug  6 2012 14:16:54) [Linux]
    >>> $model = new Model_Mymodel;
    >>> $model->mycolumn = 'foo';
    >>> $model->save();
    true

    mysql> select * from mymodels;
    +----+----------+------------+------------+
    | id | mycolumn | created_at | updated_at |
    +----+----------+------------+------------+
    |  1 | foo            |                0 |                 0 |


    If the advice is to move to 1.5 develop, how safe is it to follow 1.5/develop git on a production environment? 

  • HarroHarro
    Accepted Answer
    According to the "oil console" output, you're already on 1.5-dev.

    I use it in production everywhere, it's the quickest way for me to find stability issues. Most people stay on 1.4, so issues with 1.5 will only be reported after release, and I would like to see then before... ;-)

    I've looked in the code, and it looks like a bug: the properties list is generated before checking if the timestamp fields need to be added. I'll fix that later today.
  • Thanks for looking into it,

    im not on 1.5, or at least, not on the main repo, but it looks like submodules are. That seems to happen if you just run a clone from the 1.4 repo.

    $ git branch -a
    * 1.4/master
      remotes/origin/1.0/master
      remotes/origin/1.1/master
      remotes/origin/1.2/develop
      remotes/origin/1.2/master
      remotes/origin/1.3/develop
      remotes/origin/1.3/master
      remotes/origin/1.4/develop
      remotes/origin/1.4/master
      remotes/origin/1.5/develop
      remotes/origin/HEAD -> origin/1.4/master

    $ cd packages/oil
    $ git branch -a
    * 1.5/develop
      remotes/origin/1.0/master
      remotes/origin/1.1/master
      remotes/origin/1.2/develop
      remotes/origin/1.2/master
      remotes/origin/1.3/develop
      remotes/origin/1.3/master
      remotes/origin/1.4/develop
      remotes/origin/1.4/master
      remotes/origin/1.5/develop
      remotes/origin/HEAD -> origin/1.5/develop

    I just checked this on a fresh clone:  git clone --recursive git://github.com/fuel/fuel.git

    Can this cause issues?
  • Yes, that is possible. Did I already mention I hate submodules? ;-)

    Pushed a fix to 1.5/develop.
  • Correction, that is not possible.

    A submodule is a reference to a specific commit, after installing them your modules are 'headless', they don't point to any branch. If yours point to a specific branch, you must have done a "git checkout", or you use a tool which does.
  • Right, I did do a git checkout after i saw they were headless.  Is that going to cause problems?

  • Mixing versions might cause problems, there are dependencies between packages and some of the core classes. It's best to keep it all the same version as long as we haven't sorted the tight coupling issue.
  • It seems the headless state is not quite 1.4/master either. You're saying I should create a local checkout based on origin/1.4/master?


  • No, submodules are pinned on a specific commit hash, which is not related to any particular branch, it's just a snapshot of the repo frozen in time.

    In general the references should be in sync, but as it is a lot of manual updating to keep them in sync, it is possible that they not up to date.

    However, for every release we try to make sure the references in fuel/fuel point to the last commit in the master branch of the corresponding version in all submodules.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion