Выдавание исключения в автопогрузчике SPL?
Я жил в стране хранимой процедуры ETL для многотерабайтного хранилища данных SQL Server. Это решение было принято еще в 2001 году, когда .NET был 1.0, поэтому VB6 был альтернативой языка программирования, а SSIS еще не существовал - это был DTS. Я могу сказать вам, что были преимущества и недостатки, как и все.
Некоторые соображения:
- Если все в вашей команде понимают SQL, легко разобраться в хранимых процессах. SQL - широко известный навык, который может быть полезен, если у вас много писателей / читателей ETL. Вы должны быть не просто обычным пользователем SSIS, чтобы понять, что он делает. Графический поток высокого уровня удобен для документирования, но если кому-то нужно разобраться с духом, ему лучше знать SSIS.
- SQL - это боль в модульности. Если вы используете UDF, вы получите огромный удар по производительности. Вы будете писать похожий код в нескольких местах, и вы будете ненавидеть себя за это, но часто в сценариях ETL производительность является главной. Служба SSIS поможет вам модульно структурировать ваши задачи.
- Не ожидайте, что сможете легко использовать контроль источников с SSIS. SQL - нет проблем. SSIS использует ужасные XML-файлы, которые можно зарегистрировать, но удачи в предыдущих версиях, чтобы увидеть, что изменилось и когда.
- Вы должны думать о своих SP по модульному принципу, хотя трудно сделать их такими модульными, как бы вам хотелось. Используйте временные таблицы для разделения вашей обработки. Поместите индексы в эти временные таблицы, прежде чем использовать их. Не пытайтесь делать слишком много сразу. Комментируйте все.
- Если вы используете курсоры, вы делаете это неправильно. Не бойтесь связать какое-то внешнее консольное приложение, написанное вами на выбранном вами языке, для выполнения некоторых задач, для которых SQL просто не предназначен.
Кстати, после того, как я покинул эту компанию, они наконец обновили базу данных с SQL 2000 до 2008 и медленно перешли с хранимых процедур на SSIS. В моей новой компании у нас есть SSIS, но после его использования мы все согласились с тем, что наш заказный .NET ETL лучше подходит для наших целей. Каждый идет своим путем. Решение должно сбалансировать обслуживание и производительность, а также набор навыков вашей команды и набор навыков пула заданий в вашем регионе.
2 ответа
Это не ошибка, это проектное решение :
Примечание : исключения, возникающие в функции
__ autoload, не могут быть перехвачены блокcatchи приводит к фатальной ошибке.
Причина в том, что может быть более одного обработчика автозагрузки, и в этом случае вы не хотите, чтобы первый обработчик генерировал исключение и обходил второй обработчик. Вы хотите, чтобы у вашего второго обработчика была возможность автозагрузки своих классов. Если вы используете библиотеку, которая использует функцию автозагрузки, вы не хотите, чтобы она обходила ваш обработчик автозагрузки, потому что они генерируют исключения внутри своего автозагрузчика.
Если вы хотите проверить, можете ли вы создать экземпляр класса, используйте class_exists и передайте true в качестве второго аргумента (или оставьте его, true по умолчанию):
if (class_exists('foobarDomain', $autoload = true)) {
$domain = new foobarDomain();
} else {
echo 'Class not found';
}
Согласно комментариям в документации для spl_autoload_register , из автозагрузчика можно вызвать другую функцию, которая, в свою очередь, вызовет исключение.
class SPLAutoLoader{
public static function autoloadDomain($className) {
if(file_exists('test/'.$className.'.class.php')){
require_once('test/'.$className.'.class.php');
return true;
}
self::throwFileNotFoundException();
}
public static function throwFileNotFoundException()
{
throw new Exception('File not found');
}
} //end class
//start
spl_autoload_register( array('SPLAutoLoader', 'autoloadDomain') );
try{
$domain = new foobarDomain();
}catch(Exception $c){
echo 'File not found';
}