We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 41406 ☆ A M B ☆
    • 30 Posts
    I'm working on a custom component that utilizes a custom db table. One part of the script checks for a matching record in the database, and if none exists creates a new one. This works fine on the first iteration, but once a record is in the db, xPDO starts throwing error messages as follows:

    "Instantiated a derived class modSnippet that is not a subclass of the requested class pmsExampleClass"

    So... basically... wtf... can anyone shed any light on what this particular gem of feedback actually means? Why would modx instantiate a class the isn't the type requested? Is this an issue with the schema/classmap or the script itself?

    Schema:
    <?xml version="1.0" encoding="UTF-8"?>
    <model package="pms" baseClass="xPDOObject" platform="mysql" tablePrefix="pms_" defaultEngine="MyISAM" version="1.1">
        <object class="pmsMapRecord" table="records" extends="xPDOSimpleObject">
            <field key="package" dbtype="varchar" precision="100" phptype="string" null="false" default="" />
            <field key="class_key" dbtype="varchar" precision="100" phptype="string" null="false" default="" />
            <field key="migrate_id" dbtype="varchar" precision="100" phptype="string" null="false" default="" />
            <field key="local_pk" dbtype="int" precision="11" phptype="string" null="false" default="" />
            <field key="updated" dbtype="int" precision="16" phptype="string" null="false" default="0" />
            
            <alias key="local_id" field="local_pk" />
            
        </object>
    </model>


    Script:
    // Check for an existing record
           $record = self::$modx->getObject('pmsMapRecord',array(
                    'package' => $pkgName,
                    'class_key' => $classKey,
                    'local_pk' => $localId
                ));
           if($record !== false){
               // Return the existing id
               return $record->get('migrate_id'); 
           };
           // Generate a new id
           $all = self::$modx->getCollection('pmsMapRecord',array(
                    'package' => $pkgName,
                    'class_key' => $classKey
                ));
           $newId = "$classKey-".count($all);
           // Save new record
           $new = self::$modx->newObject('pmsMapRecord',array(
                    'package' => $pkgName,
                    'class_key' => $classKey,
                    'local_id' => $localId,
                    'migrate_id' => $newId,
                    'updated' => time()
                ));
           $new->save();

    This question has been answered by opengeek. See the first response.

    [ed. note: alanpich last edited this post 13 years, 10 months ago.]
    • discuss.answer
      • 22303 MODX Staff
      • 10,725 Posts
      The column name class_key has special meaning in xPDO. This is used with tables that use single-table inheritance to indicate what derivative class is to be instantiated when the row is loaded as an xPDOObject. Just alter the name of the column to something else, and you can avoid this issue.
        • 41406 ☆ A M B ☆
        • 30 Posts
        That'd explain it... nice one! Thanks for that, have been scratching my head over it for hours.

        Is there a particular reason only a fraction (just site_content off the top of my head) of the core tables implement this behaviour?