We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 18373 ☆ A M B ☆
    • 3,141 Posts
    I’m working on a lil’ project I hope to be able of releasing to the public in some time as a (really simple) versioning tool.

    Running into a lil’ problem now tho.

    I’ve built my table in PhpMyAdmin, and used the snippet from Bob’s site to built a schema / model out of it. The table’s name is extra_versionx and the related files are in core/components/versionx/..

    This is how I declare the package in my plugin w/ random comment:
          // Okay, let's register our custom db table with xPDO
          $path = MODX_CORE_PATH . 'components/versionx/model/';
          $fetchModel = $modx->addPackage('versionx', $path, 'extra_');
          // Check if we got the model running. If not, write to the error.log
          if (!$fetchModel) {
            $modx->log(modX::LOG_LEVEL_ERROR, 'Error fetching versionX package in xPDO');
          }

    That all works and the error.log is not filled with the error.

    Making a new object works fine:
            $vX_new = $modx->newObject('versionx');
            // Set the content
            $vX_new->set('content',$resource->getContent());
            // Loop through the selected fields and set its data.
            foreach ($vX_fields as $field) {
              $vX_new->set($field, $resource->get($field));
            }


    .. but as one field is dependant of data already existing I’m doing a lookup:

                // Try to find the last revision ("from"). If not found, set to 0   
                $vX_findlastrev = $modx->newQuery('versionx');
                $vX_findlastrev->where(array(
                  'id' => $resource->get('id')));
                $vX_findlastrev->sortby('time', 'DESC');
                $vX_lastrev = $modx->getCollection('versionx',$vX_findlastrev);


    And that’s when I’m getting an error:

    [2010-12-21 20:16:55] (ERROR @ /dev/versioning/connectors/resource/index.php) Could not get table name for class: versionx
    [2010-12-21 20:16:55] (ERROR @ /dev/versioning/connectors/resource/index.php) Error 42000 executing statement:
    Array
    (
    [0] => 42000
    [1] => 1064
    [2] => You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ’FROM AS `versionx` WHERE `versionx`.`id` = ’1’ ORDER BY time DESC’ at line 1
    )
    huh

    By commenting the last snippet of code (doing the lookup) I’ve managed to pin that section down as the one causing the error. From what I understand it has trouble finding the package (which worked fine just a couple of lines up when making the new object!) and because of that it can’t find the right table name (extra_versionx) and queries "versionx" as tablename.


    Did I miss anything, or is this a bug that it simply.. forgets the table prefix?
      Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

      Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
      • 18373 ☆ A M B ☆
      • 3,141 Posts
      Managed to solve part of the problem (Versionx instead of versionx) with a number of changes in the code, but now it’s giving another error (once every time the plugin runs).

      To clarify: the problem of being unable to load the class, and not using the table prefix was that the object name used (in $modx->newQuery(’versionx’);) didn’t match the class name, which is Versionx (look it up in your model folder, the files with .class.php)


      Full plugin code: http://pastebin.com/SDUr6DpY

      Error:
      [2010-12-21 21:28:04] (ERROR @ /dev/versioning/connectors/resource/index.php) Instantiated a derived class modDocument that is not a subclass of the requested class Versionx


      The code works as expected now, but I want that error gone.



      Modified:
      Managed to solve the error by changing a field name in the db/model from "class_key" to "class", thus avoiding xPDO from thinking it’s an actual class_key, while merely a reference to it..
        Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

        Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.