Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[xpdo3] addPackage ignores $prefix, while setPackage uses it incorrectly #161

Open
wshawn opened this issue Sep 6, 2019 · 6 comments
Open
Labels
Milestone

Comments

@wshawn
Copy link

wshawn commented Sep 6, 2019

if (!$this->modx->addPackage('Database', $this->config['modelPath'] , $this->prefix)) 

Creates the tables in the schema, but with the modx_ prefix.

switching it to

if (!$this->modx->setPackage('Database', $this->config['modelPath'] , $this->prefix)) {

Performs as expected subsequently allowing tables to be created correctly. But also has the problem of changing the prefix for the MODX\Revolution package.

[2019-09-06 12:29:24] (ERROR @ /home/wshawn/public_html/core/src/Revolution/modParser.php : 508) Could not find snippet with name ServiceList.
[2019-09-06 12:29:24] (ERROR @ /home/wshawn/public_html/core/vendor/xpdo/xpdo/src/xPDO/Om/xPDOObject.php : 529) Error 42S02 executing query: SELECT `modSnippet`.`id` AS `modSnippet_id`, `modSnippet`.`source` AS `modSnippet_source`, `modSnippet`.`property_preprocess` AS `modSnippet_property_preprocess`, `modSnippet`.`name` AS `modSnippet_name`, `modSnippet`.`description` AS `modSnippet_description`, `modSnippet`.`editor_type` AS `modSnippet_editor_type`, `modSnippet`.`category` AS `modSnippet_category`, `modSnippet`.`cache_type` AS `modSnippet_cache_type`, `modSnippet`.`snippet` AS `modSnippet_snippet`, `modSnippet`.`locked` AS `modSnippet_locked`, `modSnippet`.`properties` AS `modSnippet_properties`, `modSnippet`.`moduleguid` AS `modSnippet_moduleguid`, `modSnippet`.`static` AS `modSnippet_static`, `modSnippet`.`static_file` AS `modSnippet_static_file`, `Source`.`id` AS `Source_id`, `Source`.`name` AS `Source_name`, `Source`.`description` AS `Source_description`, `Source`.`class_key` AS `Source_class_key`, `Source`.`properties` AS `Source_properties`, `Source`.`is_stream` AS `Source_is_stream` FROM `bbl_site_snippets` AS `modSnippet` LEFT JOIN `bbl_media_sources` `Source` ON `modSnippet`.`source` = `Source`.`id` WHERE `modSnippet`.`name` = ? ORDER BY `modSnippet`.`id` ASC  - Array
(
    [0] => 42S02
    [1] => 1146
    [2] => Table 'wshawn_master.bbl_site_snippets' doesn't exist
)

[2019-09-06 12:29:24] (ERROR @ /home/wshawn/public_html/core/src/Revolution/modParser.php : 508) Could not find snippet with name ServiceList.
[2019-09-06 12:29:24] (ERROR @ /home/wshawn/public_html/core/vendor/xpdo/xpdo/src/xPDO/Om/xPDOObject.php : 227) Error 42S02 executing statement: 
Array
(
    [0] => 42S02
    [1] => 1146
    [2] => Table 'wshawn_master.bbl_session' doesn't exist
)

[2019-09-06 12:29:24] (ERROR @ /home/wshawn/public_html/core/vendor/xpdo/xpdo/src/xPDO/Om/xPDOObject.php : 1443) Error 42S02 executing statement:
INSERT INTO `bbl_session` (`id`, `access`, `data`) VALUES ('3e741417857274c8a3c53eab6683b60f', 1567772964, 'modx.user.contextTokens|a:1:{s:3:\"mgr\";i:1;}manager_language|s:2:\"en\";modx.user.0.resourceGroups|a:1:{s:3:\"mgr\";a:0:{}}modx.user.0.attributes|a:1:{s:3:\"mgr\";a:5:{s:16:\"modAccessContext\";a:1:{s:3:\"web\";a:1:{i:0;a:3:{s:9:\"principal\";i:0;s:9:\"authority\";s:1:\"0\";s:6:\"policy\";a:1:{s:4:\"load\";b:1;}}}}s:22:\"modAccessResourceGroup\";a:0:{}s:17:\"modAccessCategory\";a:0:{}s:28:\"sources.modAccessMediaSource\";a:0:{}s:18:\"modAccessNamespace\";a:0:{}}}modx.mgr.user.token|s:52:\"modx5d694e8518de66.43856135_15d7250aaa8b745.88377583\";modx.mgr.session.cookie.lifetime|i:0;modx.mgr.user.config|a:0:{}')
Array
(
    [0] => 42S02
    [1] => 1146
    [2] => Table 'wshawn_master.bbl_session' doesn't exist
)

As mentioned in #154 PSR-4 is a bit of a pain. The Parser can create the base files anywhere you point it to, but then xpdo->addPackage / setPackage can not load them.

06 12:40:26] (ERROR @ /home/wshawn/public_html/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 652) Could not load class: SanityLLC\Devotional\Database\bblAward from mysql.sanityllc\devotional\database\bblaward
[2019-09-06 12:40:26] (ERROR @ /home/wshawn/public_html/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 652) Could not load class: SanityLLC\Devotional\Database\bblAwardPatron from mysql.sanityllc\devotional\database\bblawardpatron
[2019-09-06 12:40:26] (ERROR @ /home/wshawn/public_html/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 652) Could not load class: SanityLLC\Devotional\Database\bblAwardType from mysql.sanityllc\devotional\database\bblawardtype
[2019-09-06 12:40:26] (ERROR @ /home/wshawn/public_html/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 652) Could not load class: SanityLLC\Devotional\Database\bblCache from mysql.sanityllc\devotional\database\bblcache
[2019-09-06 12:40:26] (ERROR @ /home/wshawn/public_html/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 652) Could not load class: SanityLLC\Devotional\Database\bblLanguage from mysql.sanityllc\devotional\database\bbllanguage
[2019-09-06 12:40:26] (ERROR @ /home/wshawn/public_html/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 652) Could not load class: SanityLLC\Devotional\Database\bblPatron from mysql.sanityllc\devotional\database\bblpatron
[2019-09-06 12:40:26] (ERROR @ /home/wshawn/public_html/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 652) Could not load class: SanityLLC\Devotional\Database\bblPatronHistory from mysql.sanityllc\devotional\database\bblpatronhistory
[2019-09-06 12:40:26] (ERROR @ /home/wshawn/public_html/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 652) Could not load class: SanityLLC\Devotional\Database\bblReadingPlan from mysql.sanityllc\devotional\database\bblreadingplan
[2019-09-06 12:40:26] (ERROR @ /home/wshawn/public_html/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 652) Could not load class: SanityLLC\Devotional\Database\bblReadingPlanContent from mysql.sanityllc\devotional\database\bblreadingplancontent
[2019-09-06 12:40:26] (ERROR @ /home/wshawn/public_html/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 652) Could not load class: SanityLLC\Devotional\Database\bblVolume from mysql.sanityllc\devotional\database\bblvolume

The Not Found is solved by using an autoloader within the main addon Class, but then appears to not be needed.

Using the exact same format as the MODX installer:

$this->modx->addPackage('SanityLLC\Devotional', MODX_CORE_PATH . 'components/', $this->prefix);

$this->prefix is set to 'bbl_'

The prefix is ignored. I even tried placing it within the schema like we did in legacy versions.

For what it is worth, I do have PSR-4 working. It is just using the wrong prefix.

@wshawn
Copy link
Author

wshawn commented Dec 18, 2019

var_dump ($xpdo->packages):

 ["Om"]=>
  array(2) {
    ["path"]=>
    string(57) "/home/wshawn/public_html/core/vendor/xpdo/xpdo/src/xPDO/"
    ["prefix"]=>
    string(5) "modx_"
  }
  ["Revolution"]=>
  array(2) {
    ["path"]=>
    string(35) "/home/wshawn/public_html/core/src/"
    ["prefix"]=>
    string(5) "modx_"
  }
  ["Revolution\Registry\Db"]=>
  array(2) {
    ["path"]=>
    string(35) "/home/wshawn/public_html/core/src/"
    ["prefix"]=>
    string(5) "modx_"
  }
  ["Revolution\Sources"]=>
  array(2) {
    ["path"]=>
    string(35) "/home/wshawn/public_html/core/src/"
    ["prefix"]=>
    string(5) "modx_"
  }
  ["Revolution\Transport"]=>
  array(2) {
    ["path"]=>
    string(35) "/home/wshawn/public_html/core/src/"
    ["prefix"]=>
    string(5) "modx_"
  }
  ["Devotional"]=>
  array(2) {
    ["path"]=>
    string(51) "/home/wshawn/public_html/core/components/SanityLLC"
    ["prefix"]=>
    string(4) "bbl_"
  }

This is still happening for the MODX 3 Alpha build. If I use setPackge MODX 3 Alpha can't see some of its own databases as the prefix gets swapped to bbl_. If I use addPackage the prefix is still ignored.

@wshawn wshawn changed the title addPackage with prefix ignores $prefix, while setPackage uses it [xpdo3] addPackage with prefix ignores $prefix, while setPackage uses it Dec 18, 2019
@wshawn wshawn changed the title [xpdo3] addPackage with prefix ignores $prefix, while setPackage uses it [xpdo3] addPackage ignores $prefix, while setPackage uses it Dec 18, 2019
@wshawn wshawn changed the title [xpdo3] addPackage ignores $prefix, while setPackage uses it [xpdo3] addPackage ignores $prefix, while setPackage uses it incorrectly Dec 18, 2019
@opengeek
Copy link
Member

Honestly, I've been wanting to get rid of the package-specific table prefixes. I really don't see the point in them.

@wshawn
Copy link
Author

wshawn commented Dec 18, 2019

Its just a mess to deal with with everything modx_ . At least let us use the table name defined in the schema. If we want to have a prefix, we could just do it there manually -- as long as it is not being forced somewhere else. I have sites with multiple projects with up to 75 tables in addition to the CMS.

@opengeek
Copy link
Member

The intention of the prefix has always been to apply it to the entire database being connected to so that multiple instances of the same tables could be kept in a single database container. If you are using a prefix with MODX, then use it with the rest of the tables in the same database. If you don't want the prefix, then don't use one.

@wshawn
Copy link
Author

wshawn commented Dec 18, 2019

OK. So, I reworked the schema tables. modx_ is still applied per your container statement. To avoid collisions I removed the prefix and altered the table names to match the namespace and package. Resulting in modx_namespace_package_tablename (i.g. modx_sanity_devotional_awards) from

<object class="bblAward" table="sanity_devotional_awards" extends="xPDO\Om\xPDOSimpleObject" >

I guess with namespaces we can also get rid of the prefix before the classnames now.

@wshawn wshawn closed this as completed Dec 18, 2019
@opengeek opengeek reopened this Dec 18, 2019
@opengeek
Copy link
Member

I'm still going to look into fixing the issue as it is a feature of xPDO currently. I was just mentioning that it didn't make a lot of sense to me to create tables with different prefixes. But that said, considering working with tables from other systems where you don't have control of how they are created can be simplified by getting this working properly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants