🔴 Wrapping up v4.3.3 (Issues with SqlMap and MySql)

[belisoful]

This needs to be fixed before we ship 4.3.3. Given the importance of this class. This is one of the few exceptions to changing this late. Other parts were fixed up in an earlier PR and this is finishing the fix on that bug.

prado/framework/Prado.php

Line 432 in 469bf5c

return $namespace;

public static function using($namespace): ?string
	{
		$namespace = static::prado3NamespaceToPhpNamespace($namespace);

		if (isset(self::$_usings[$namespace])) {
			return $namespace . '\\';
		}
		if (class_exists($namespace, false) ||
			interface_exists($namespace, false) ||
			trait_exists($namespace, false)) {
			return $namespace;
		}
	...

needs to be this:

	public static function using($namespace): ?string
	{
		$namespace = static::prado3NamespaceToPhpNamespace($namespace);

		if (isset(self::$_usings[$namespace])) {
			return $namespace . '\\';
		}
		if (class_exists($namespace, false) ||
			interface_exists($namespace, false) ||
			trait_exists($namespace, false)) {
			if (($shortPos = strrpos($namespace, '\\')) !== false) {
				$shortName = substr($namespace, $shortPos + 1);
				if (!class_exists($shortName, false) &&
					!interface_exists($shortName, false) &&
					!trait_exists($shortName, false)) {
					class_alias($namespace, $shortName);
				}
			}
			return $namespace;
		}

[belisoful]

@ctrlaltca Given the direction of Prado v4.4 in isolating ActiveRecord and SqlMap in their own repos, The current state of v4.3.3 may be "reasonable." Basic Data supports 3rd parties. bringing 3rd party to AR and SqlMap is beyond 4.3.3 scope.

Before you start tagging the release, please let me know so I can scope things out in Data AS IS for a less aggressive 3rd party Data roll-out. Let me know so I can audit the current state for the transition of AR and SqlMap to their own repo. (meaning, 3rd party support for those subsystems will not be in 4.3.3).

Adding 3rd party db support in AR and SqlMap added a lot of complexity, too much.

[belisoful]

@ctrlaltca We should probably add friendsofphp/php-cs-fixer and phpstan/phpstan to the 'require-dev' of composer.json and remove it from the "devtools" script.

[belisoful]

@ctrlaltca There is a significant issue with MySql and case sensitivity with table names in Metadata, exposed by #1209 - found in the relocation of SqlMap to its own repo #1168.

The blocker on 4.3.3 is #1209 for 4.3.3. I suspected serious (untested) issues in Data for a quite a while. That's why I have been focused on it and getting it unit tested and refactored. I also get the sense that such brokenness led to its non-use. the issue just wasn't worth new users time and they never got that it was an error.

SqlMap is technically ready in its own repo and pending #1209 in Prado (Data fixes). We could remove SqlMap for 4.3.3 too. The current prado-sqlmap is a private repo in pradosoft. I'm updating only the current code to modern standards, ensuring its fully unit tested, proofing SqlMap "as is." I'm going to look through the SqlMap issues in Prado and resolve them (hopefully). clean it all up. That could be 4.3.3 SqlMap. It's turning up real issues in Prado Data that have needed resolution.

My intention is after tagging the proofed 4.3.3 (release or not), is to then start updating it to the current BATIS standard (myBATIS? if I recall correctly). the new updated SqlMap would be in "for" Prado v4.4 if changes to Data are needed. Otherwise 4.3.3 users could get the v4.4 improvements for SqlMap.

moving SqlMap to its own repo presents the same challenges in dependency coordination with 4.3.3 as 4.4.

PS. I'd like to move RPC to a separate repo because it's technically "legacy." We may want to consider moving Prado IO to a separate Repo, like the other platforms (symphony, yii, laravel, etc etc). It's probably about time we take this leap. I prefer simplicity and obviousness as well. This may be the direction we start taking for Prado 5.

My thoughts for Prado 5:

• move into PSR compliance. Prado is not HUGE, so I think this is possible.
• We can use interfaces from others that make sense (yii, laravel) as well.
• We hand roll our own where others aren't optimal (eg. Clock services @ Yii and their discussion of it aren't up to my spec)
• We institute a clock service.
• We remove the "T" prefix.
• Can we remove Prado 3 namespacing? or would it need extension for plugins?

[belisoful]

My apologies on the delay for wrapping this up. The issue is forward compatibility. v4.4 is shaping up to have very interesting changes. I'd like the plugin architecture of v4.4 to be in v4.3.3. That was only recently resolved with the plugin class map and error messages via composer.json extra (directly in the file or by file).

If we ever partition v4.4 IO into a separate sub-repo, then v4.3.3 could theoretically pick it up; all things being equal.

FYI, This plugin architecture does set the stage for breaking up PRADO into pieces rather than continue being monolithic.