Смысл в том, что мы при произвольном запросе будем знать из какой таблицы эта
колонка и можем, используя метаинформацию, заданную в схеме, конструировать
свои типы данных, а не дефолтные Пгшные. Например у нас есть таблица
UserId,(BIGINT) ACL(JSON), делая что-то типа: $db->query("SELECT * FROM users
WHERE userid = ?", $userid)->ACL->check_rights_for("MyACLKey"). Или если у нас
там id со связанной таблицей, то мы можем при обращении к этому полю прозрачно
выполнить SQL запрос на выборку информации по этому полю. Вариантов море. И это
довольно хороший сахар.
Fri, 16 Jan 2015 21:08:01 +0100 от PEF Secure <[email protected]>:
>On Friday, January 16, 2015 22:27:05 [email protected] wrote:
>> Раз уж тут пошла такая пьянка... Давайте сделаем ORM для PostgreSQL с
>> поддержкой асинхронности и возможностью прямого SQL запроса и
>> конвертирования результатов в спец типы.
>>
>> Идея основана на том, что EXPLAIN VERBOSE всегда расскажет какие поля и
>> откуда взяты (даже в случае с WITH), вот допустим:
>>
>> EXPLAIN VERBOSE WITH foo AS (SELECT * FROM test) SELECT * FROM foo;
>> QUERY PLAN
>> ----------------------------------------------------------------------------
>> - CTE Scan on foo (cost=21.60..44.80 rows=1160 width=40)
>> Output: foo.id, foo.data
>> CTE foo
>> -> Seq Scan on pg_temp_111.test (cost=0.00..21.60 rows=1160 width=40)
>> Output: test.id, test.data
>>
>> Смысл в том, что на каждый raw запрос (с кешированием, понятно) запрашивать
>> EXPLAIN этого запроса и по результатам строить аксессоры. Или не строить ))
>
>Не совсем понятен смысл именно EXPLAIN. Для аксессоров достаточно сделать
>execute и ещё до фетча уже будет всё выдано в %fields = %{$sth->{NAME_hash}};
>--
>PEF Developer
>--
>Moscow.pm mailing list
>[email protected] | http://moscow.pm.org
--
Moscow.pm mailing list
[email protected] | http://moscow.pm.org
