From denis.fedoseev на gmail.com  Sat Oct  1 01:43:07 2011
From: denis.fedoseev на gmail.com (Denis Fedoseev)
Date: Sat, 1 Oct 2011 12:43:07 +0400
Subject: [Moscow.pm] =?utf-8?b?0JjQvdGC0LXRgNCw0YLQvtGAINC40L3QuNGG0Lg=?=
 =?utf-8?b?0LDQu9C40LfQuNGA0YPQtdGCINGB0YHRi9C70LrRgyDQvdCwINC80LDRgdGB?=
 =?utf-8?b?0LjQsi/RhdC10Yg=?=
In-Reply-To: <CAAPa60g8783vYsrLeK_XB__8XCtu=dOjpPFecSpM5fCP9+DCWg@mail.gmail.com>
References: <CACEsYN5GcsxGOZLHta=yNHctdCM1=xOcGTrYA7xwe5FagsNaqQ@mail.gmail.com>
	<CANTXRvSv02aB5dy2Tvht1dRYtq5A--8PSy_XZXmaAmAMsknc1g@mail.gmail.com>
	<CAJG5KK6SOruEQGcPW6B=1NZWTxFByaEmqfu6g4a0vF74BRL7qQ@mail.gmail.com>
	<CACEsYN6QJdM3NiRVtSMT_ptZr9xotdM+G8UKL24sst4UR6OkMg@mail.gmail.com>
	<D7127F46-4E30-44F8-9A7D-17B97F8EB213@gmail.com>
	<CABXEPAG+Lb1PJTtKUvTuD_2jPzv+XLZu3EURy45yYd=0NZF1KQ@mail.gmail.com>
	<CAJG5KK5g8MN82JoS7wkDBiH9sEMjWE34kOJ7w9+iD4hg1OG=Vg@mail.gmail.com>
	<CAAPa60g8783vYsrLeK_XB__8XCtu=dOjpPFecSpM5fCP9+DCWg@mail.gmail.com>
Message-ID: <BC2E1C16-47DF-4F49-A87E-93E7EF006AA6@gmail.com>

Это паранойя в том плане  - что если тебе нужно разименовать переменную и Получить массив или хэш - то смысла в такой проверке нет. Если тебе нужно Проверить что ссылка это массив или хэш - то тогда надо пользоваться ref eq 'ARRAY'


On Sep 30, 2011, at 11:52 PM, Oleg Kostyuk wrote:

> Про перегрузку соглашусь, но почему использование ref eq 'ARRAY' - это
> паранойя? Это сплошь и рядом используется, например в том же
> DBIx::Class. Обоснуйте-ка, милейший!
> 
> 30 сентября 2011 г. 16:51 пользователь Анатолий Шарифулин
> <sharifulin на gmail.com> написал:
>> Вместо:
>> @$t2 = @$t3;
>> обычно пишу:
>> $t2 = [ @$t3 ];
>> 
>> Ну и: нужно быть уверенным в том, что ты разыменовываешь, если не уверен, то
>> @{ $t2 || [] };
>> Только не нужно быть пароноиком и использовать ref eq 'ARRAY' или
>> использовать перегрузку, когда не известен тип входной структуры.
>> Такая практика меня ещё ни разу не привела к подобным ошибкам.
>> 
>> 2011/9/30 Alexander Onokhov <ccnweb на gmail.com>
>>> 
>>> Да про lvalue хорошо
>>> 
>>> @$t2 = (1,2,3);  # нет ошибки
>>> 
>>> 
>>> On Fri, Sep 30, 2011 at 4:42 PM, Dmitry Karpich <meettya на gmail.com> wrote:
>>>> 
>>>> 
>>>> http://stackoverflow.com/questions/6419618/perl-vivification-question-while-dereferencing-undefined-array-reference
>>>> 
>>>> http://stackoverflow.com/questions/2206836/why-does-perl-autovivify-in-this-case
>>>> stackoverflow наш друг :)
>>>> 
>>>> On Sep 30, 2011, at 5:38 PM, Иван Бессарабов wrote:
>>>> 
>>>> Ок. А почему в списочном контексте происходит инициализация ссылки?
>>>> 
>>>> 30 сентября 2011 г. 17:32 пользователь Анатолий Шарифулин
>>>> <sharifulin на gmail.com> написал:
>>>> 
>>>> Потому что разный контекст.
>>>> 
>>>> foreach (scalar @$t1) {}
>>>> 
>>>> Вот так будет идентично ифу.
>>>> 
>>>> 
>>>> 2011/9/30 Andrew Shitov <andy на shitov.ru>
>>>> 
>>>> Потому что $t1 станет другим после foreach, а $t2 не станет :-)
>>>> 
>>>> $ perl -E'use strict; use Data::Dumper; my $t; print Dumper($t); for
>>>> 
>>>> (@$t) {}; print Dumper($t);'
>>>> 
>>>> $VAR1 = undef;
>>>> 
>>>> $VAR1 = [];
>>>> 
>>>> 
>>>> 2011/9/30 Иван Бессарабов <ivan на bessarabov.ru>:
>>>> 
>>>> Я не могу понять из-за чего происходит такое поведение.
>>>> 
>>>> Покажите, пожалуйста, кусок доки где объянено, почему так.
>>>> 
>>>> 
>>>> #!/usr/bin/perl
>>>> 
>>>> use strict;
>>>> 
>>>> use warnings;
>>>> 
>>>> use 5.010;
>>>> 
>>>> use Data::Dumper;
>>>> 
>>>> my ($t1, $t2);
>>>> 
>>>> foreach (@$t1) {} # почему-то не вызывает ошибку
>>>> 
>>>> say Dumper $t1;
>>>> 
>>>> say '' if @$t2; # вызывает ошибку, как и ожидалось
>>>> 
>>>> say 'end';
>>>> 
>>>> --
>>>> 
>>>> Moscow.pm mailing list
>>>> 
>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> 
>>>> Andrew Shitov
>>>> 
>>>> ______________________________________________________________________
>>>> 
>>>> andy на shitov.ru | http://shitov.ru
>>>> 
>>>> --
>>>> 
>>>> Moscow.pm mailing list
>>>> 
>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>> 
>>>> 
>>>> 
>>>> --
>>>> 
>>>> С уважением,
>>>> 
>>>>  Анатолий Шарифулин.
>>>> 
>>>> --
>>>> 
>>>> Moscow.pm mailing list
>>>> 
>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>> 
>>>> 
>>>> --
>>>> Moscow.pm mailing list
>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>> 
>>>> 
>>>> --
>>>> Moscow.pm mailing list
>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Alexander
>>> 
>>> --
>>> Moscow.pm mailing list
>>> moscow-pm на pm.org | http://moscow.pm.org
>>> 
>> 
>> 
>> 
>> --
>> С уважением,
>>  Анатолий Шарифулин.
>> 
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>> 
>> 
> 
> 
> 
> -- 
> Sincerely yours,
> Oleg Kostyuk (CUB-UANIC)
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org


From cub.uanic на gmail.com  Sat Oct  1 12:15:50 2011
From: cub.uanic на gmail.com (Oleg Kostyuk)
Date: Sat, 1 Oct 2011 22:15:50 +0300
Subject: [Moscow.pm] =?utf-8?b?0JjQvdGC0LXRgNCw0YLQvtGAINC40L3QuNGG0Lg=?=
	=?utf-8?b?0LDQu9C40LfQuNGA0YPQtdGCINGB0YHRi9C70LrRgyDQvdCwINC80LA=?=
	=?utf-8?b?0YHRgdC40LIv0YXQtdGI?=
In-Reply-To: <BC2E1C16-47DF-4F49-A87E-93E7EF006AA6@gmail.com>
References: <CACEsYN5GcsxGOZLHta=yNHctdCM1=xOcGTrYA7xwe5FagsNaqQ@mail.gmail.com>
	<CANTXRvSv02aB5dy2Tvht1dRYtq5A--8PSy_XZXmaAmAMsknc1g@mail.gmail.com>
	<CAJG5KK6SOruEQGcPW6B=1NZWTxFByaEmqfu6g4a0vF74BRL7qQ@mail.gmail.com>
	<CACEsYN6QJdM3NiRVtSMT_ptZr9xotdM+G8UKL24sst4UR6OkMg@mail.gmail.com>
	<D7127F46-4E30-44F8-9A7D-17B97F8EB213@gmail.com>
	<CABXEPAG+Lb1PJTtKUvTuD_2jPzv+XLZu3EURy45yYd=0NZF1KQ@mail.gmail.com>
	<CAJG5KK5g8MN82JoS7wkDBiH9sEMjWE34kOJ7w9+iD4hg1OG=Vg@mail.gmail.com>
	<CAAPa60g8783vYsrLeK_XB__8XCtu=dOjpPFecSpM5fCP9+DCWg@mail.gmail.com>
	<BC2E1C16-47DF-4F49-A87E-93E7EF006AA6@gmail.com>
Message-ID: <CAAPa60jf0jWwxPWQCqGcceS7aTEM_s8SG8Ra=y__8Bk5xKTryA@mail.gmail.com>

А как же без использования ref можно безопасно "разименовать
переменную и Получить массив или хэш", когда "не известен тип входной
структуры"?

(то что в кавычках - цитаты)


1 октября 2011 г. 11:43 пользователь Denis Fedoseev
<denis.fedoseev на gmail.com> написал:
> Это паранойя в том плане  - что если тебе нужно разименовать переменную и Получить массив или хэш - то смысла в такой проверке нет. Если тебе нужно Проверить что ссылка это массив или хэш - то тогда надо пользоваться ref eq 'ARRAY'
>
>
> On Sep 30, 2011, at 11:52 PM, Oleg Kostyuk wrote:
>
>> Про перегрузку соглашусь, но почему использование ref eq 'ARRAY' - это
>> паранойя? Это сплошь и рядом используется, например в том же
>> DBIx::Class. Обоснуйте-ка, милейший!
>>
>> 30 сентября 2011 г. 16:51 пользователь Анатолий Шарифулин
>> <sharifulin на gmail.com> написал:
>>> Вместо:
>>> @$t2 = @$t3;
>>> обычно пишу:
>>> $t2 = [ @$t3 ];
>>>
>>> Ну и: нужно быть уверенным в том, что ты разыменовываешь, если не уверен, то
>>> @{ $t2 || [] };
>>> Только не нужно быть пароноиком и использовать ref eq 'ARRAY' или
>>> использовать перегрузку, когда не известен тип входной структуры.
>>> Такая практика меня ещё ни разу не привела к подобным ошибкам.
>>>
>>> 2011/9/30 Alexander Onokhov <ccnweb на gmail.com>
>>>>
>>>> Да про lvalue хорошо
>>>>
>>>> @$t2 = (1,2,3);  # нет ошибки
>>>>
>>>>
>>>> On Fri, Sep 30, 2011 at 4:42 PM, Dmitry Karpich <meettya на gmail.com> wrote:
>>>>>
>>>>>
>>>>> http://stackoverflow.com/questions/6419618/perl-vivification-question-while-dereferencing-undefined-array-reference
>>>>>
>>>>> http://stackoverflow.com/questions/2206836/why-does-perl-autovivify-in-this-case
>>>>> stackoverflow наш друг :)
>>>>>
>>>>> On Sep 30, 2011, at 5:38 PM, Иван Бессарабов wrote:
>>>>>
>>>>> Ок. А почему в списочном контексте происходит инициализация ссылки?
>>>>>
>>>>> 30 сентября 2011 г. 17:32 пользователь Анатолий Шарифулин
>>>>> <sharifulin на gmail.com> написал:
>>>>>
>>>>> Потому что разный контекст.
>>>>>
>>>>> foreach (scalar @$t1) {}
>>>>>
>>>>> Вот так будет идентично ифу.
>>>>>
>>>>>
>>>>> 2011/9/30 Andrew Shitov <andy на shitov.ru>
>>>>>
>>>>> Потому что $t1 станет другим после foreach, а $t2 не станет :-)
>>>>>
>>>>> $ perl -E'use strict; use Data::Dumper; my $t; print Dumper($t); for
>>>>>
>>>>> (@$t) {}; print Dumper($t);'
>>>>>
>>>>> $VAR1 = undef;
>>>>>
>>>>> $VAR1 = [];
>>>>>
>>>>>
>>>>> 2011/9/30 Иван Бессарабов <ivan на bessarabov.ru>:
>>>>>
>>>>> Я не могу понять из-за чего происходит такое поведение.
>>>>>
>>>>> Покажите, пожалуйста, кусок доки где объянено, почему так.
>>>>>
>>>>>
>>>>> #!/usr/bin/perl
>>>>>
>>>>> use strict;
>>>>>
>>>>> use warnings;
>>>>>
>>>>> use 5.010;
>>>>>
>>>>> use Data::Dumper;
>>>>>
>>>>> my ($t1, $t2);
>>>>>
>>>>> foreach (@$t1) {} # почему-то не вызывает ошибку
>>>>>
>>>>> say Dumper $t1;
>>>>>
>>>>> say '' if @$t2; # вызывает ошибку, как и ожидалось
>>>>>
>>>>> say 'end';
>>>>>
>>>>> --
>>>>>
>>>>> Moscow.pm mailing list
>>>>>
>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Andrew Shitov
>>>>>
>>>>> ______________________________________________________________________
>>>>>
>>>>> andy на shitov.ru | http://shitov.ru
>>>>>
>>>>> --
>>>>>
>>>>> Moscow.pm mailing list
>>>>>
>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> С уважением,
>>>>>
>>>>>  Анатолий Шарифулин.
>>>>>
>>>>> --
>>>>>
>>>>> Moscow.pm mailing list
>>>>>
>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>
>>>>>
>>>>> --
>>>>> Moscow.pm mailing list
>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>
>>>>>
>>>>> --
>>>>> Moscow.pm mailing list
>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Alexander
>>>>
>>>> --
>>>> Moscow.pm mailing list
>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>
>>>
>>>
>>>
>>> --
>>> С уважением,
>>>  Анатолий Шарифулин.
>>>
>>> --
>>> Moscow.pm mailing list
>>> moscow-pm на pm.org | http://moscow.pm.org
>>>
>>>
>>
>>
>>
>> --
>> Sincerely yours,
>> Oleg Kostyuk (CUB-UANIC)
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
Sincerely yours,
Oleg Kostyuk (CUB-UANIC)

From sharifulin на gmail.com  Sat Oct  1 12:21:04 2011
From: sharifulin на gmail.com (=?KOI8-R?B?4c7B1M/Mycog+8HSycbVzMnO?=)
Date: Sat, 1 Oct 2011 23:21:04 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?6c7UxdLB1M/SIMnOycPJwczJ2snS1cXUINPT2czL?=
	=?koi8-r?b?1SDOwSDNwdPTydcvyMXb?=
In-Reply-To: <CAAPa60jf0jWwxPWQCqGcceS7aTEM_s8SG8Ra=y__8Bk5xKTryA@mail.gmail.com>
References: <CACEsYN5GcsxGOZLHta=yNHctdCM1=xOcGTrYA7xwe5FagsNaqQ@mail.gmail.com>
	<CANTXRvSv02aB5dy2Tvht1dRYtq5A--8PSy_XZXmaAmAMsknc1g@mail.gmail.com>
	<CAJG5KK6SOruEQGcPW6B=1NZWTxFByaEmqfu6g4a0vF74BRL7qQ@mail.gmail.com>
	<CACEsYN6QJdM3NiRVtSMT_ptZr9xotdM+G8UKL24sst4UR6OkMg@mail.gmail.com>
	<D7127F46-4E30-44F8-9A7D-17B97F8EB213@gmail.com>
	<CABXEPAG+Lb1PJTtKUvTuD_2jPzv+XLZu3EURy45yYd=0NZF1KQ@mail.gmail.com>
	<CAJG5KK5g8MN82JoS7wkDBiH9sEMjWE34kOJ7w9+iD4hg1OG=Vg@mail.gmail.com>
	<CAAPa60g8783vYsrLeK_XB__8XCtu=dOjpPFecSpM5fCP9+DCWg@mail.gmail.com>
	<BC2E1C16-47DF-4F49-A87E-93E7EF006AA6@gmail.com>
	<CAAPa60jf0jWwxPWQCqGcceS7aTEM_s8SG8Ra=y__8Bk5xKTryA@mail.gmail.com>
Message-ID: <CAJG5KK5nwbsyjOEnjGfejjRPDVxnb7VOcjMvrGs+pG1q=fJa-w@mail.gmail.com>

Не нужно просто заморачиваться там, где это не нужно, "милейший" :-)

2011/10/1 Oleg Kostyuk <cub.uanic на gmail.com>

> А как же без использования ref можно безопасно "разименовать
> переменную и Получить массив или хэш", когда "не известен тип входной
> структуры"?
>
> (то что в кавычках - цитаты)
>
>
> 1 октября 2011 г. 11:43 пользователь Denis Fedoseev
> <denis.fedoseev на gmail.com> написал:
> > Это паранойя в том плане  - что если тебе нужно разименовать переменную и
> Получить массив или хэш - то смысла в такой проверке нет. Если тебе нужно
> Проверить что ссылка это массив или хэш - то тогда надо пользоваться ref eq
> 'ARRAY'
> >
> >
> > On Sep 30, 2011, at 11:52 PM, Oleg Kostyuk wrote:
> >
> >> Про перегрузку соглашусь, но почему использование ref eq 'ARRAY' - это
> >> паранойя? Это сплошь и рядом используется, например в том же
> >> DBIx::Class. Обоснуйте-ка, милейший!
> >>
> >> 30 сентября 2011 г. 16:51 пользователь Анатолий Шарифулин
> >> <sharifulin на gmail.com> написал:
> >>> Вместо:
> >>> @$t2 = @$t3;
> >>> обычно пишу:
> >>> $t2 = [ @$t3 ];
> >>>
> >>> Ну и: нужно быть уверенным в том, что ты разыменовываешь, если не
> уверен, то
> >>> @{ $t2 || [] };
> >>> Только не нужно быть пароноиком и использовать ref eq 'ARRAY' или
> >>> использовать перегрузку, когда не известен тип входной структуры.
> >>> Такая практика меня ещё ни разу не привела к подобным ошибкам.
> >>>
> >>> 2011/9/30 Alexander Onokhov <ccnweb на gmail.com>
> >>>>
> >>>> Да про lvalue хорошо
> >>>>
> >>>> @$t2 = (1,2,3);  # нет ошибки
> >>>>
> >>>>
> >>>> On Fri, Sep 30, 2011 at 4:42 PM, Dmitry Karpich <meettya на gmail.com>
> wrote:
> >>>>>
> >>>>>
> >>>>>
> http://stackoverflow.com/questions/6419618/perl-vivification-question-while-dereferencing-undefined-array-reference
> >>>>>
> >>>>>
> http://stackoverflow.com/questions/2206836/why-does-perl-autovivify-in-this-case
> >>>>> stackoverflow наш друг :)
> >>>>>
> >>>>> On Sep 30, 2011, at 5:38 PM, Иван Бессарабов wrote:
> >>>>>
> >>>>> Ок. А почему в списочном контексте происходит инициализация ссылки?
> >>>>>
> >>>>> 30 сентября 2011 г. 17:32 пользователь Анатолий Шарифулин
> >>>>> <sharifulin на gmail.com> написал:
> >>>>>
> >>>>> Потому что разный контекст.
> >>>>>
> >>>>> foreach (scalar @$t1) {}
> >>>>>
> >>>>> Вот так будет идентично ифу.
> >>>>>
> >>>>>
> >>>>> 2011/9/30 Andrew Shitov <andy на shitov.ru>
> >>>>>
> >>>>> Потому что $t1 станет другим после foreach, а $t2 не станет :-)
> >>>>>
> >>>>> $ perl -E'use strict; use Data::Dumper; my $t; print Dumper($t); for
> >>>>>
> >>>>> (@$t) {}; print Dumper($t);'
> >>>>>
> >>>>> $VAR1 = undef;
> >>>>>
> >>>>> $VAR1 = [];
> >>>>>
> >>>>>
> >>>>> 2011/9/30 Иван Бессарабов <ivan на bessarabov.ru>:
> >>>>>
> >>>>> Я не могу понять из-за чего происходит такое поведение.
> >>>>>
> >>>>> Покажите, пожалуйста, кусок доки где объянено, почему так.
> >>>>>
> >>>>>
> >>>>> #!/usr/bin/perl
> >>>>>
> >>>>> use strict;
> >>>>>
> >>>>> use warnings;
> >>>>>
> >>>>> use 5.010;
> >>>>>
> >>>>> use Data::Dumper;
> >>>>>
> >>>>> my ($t1, $t2);
> >>>>>
> >>>>> foreach (@$t1) {} # почему-то не вызывает ошибку
> >>>>>
> >>>>> say Dumper $t1;
> >>>>>
> >>>>> say '' if @$t2; # вызывает ошибку, как и ожидалось
> >>>>>
> >>>>> say 'end';
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Moscow.pm mailing list
> >>>>>
> >>>>> moscow-pm на pm.org | http://moscow.pm.org
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Andrew Shitov
> >>>>>
> >>>>>
> ______________________________________________________________________
> >>>>>
> >>>>> andy на shitov.ru | http://shitov.ru
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Moscow.pm mailing list
> >>>>>
> >>>>> moscow-pm на pm.org | http://moscow.pm.org
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> С уважением,
> >>>>>
> >>>>>  Анатолий Шарифулин.
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Moscow.pm mailing list
> >>>>>
> >>>>> moscow-pm на pm.org | http://moscow.pm.org
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Moscow.pm mailing list
> >>>>> moscow-pm на pm.org | http://moscow.pm.org
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Moscow.pm mailing list
> >>>>> moscow-pm на pm.org | http://moscow.pm.org
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Alexander
> >>>>
> >>>> --
> >>>> Moscow.pm mailing list
> >>>> moscow-pm на pm.org | http://moscow.pm.org
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> С уважением,
> >>>  Анатолий Шарифулин.
> >>>
> >>> --
> >>> Moscow.pm mailing list
> >>> moscow-pm на pm.org | http://moscow.pm.org
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> Sincerely yours,
> >> Oleg Kostyuk (CUB-UANIC)
> >> --
> >> Moscow.pm mailing list
> >> moscow-pm на pm.org | http://moscow.pm.org
> >
> > --
> > Moscow.pm mailing list
> > moscow-pm на pm.org | http://moscow.pm.org
> >
>
>
>
> --
> Sincerely yours,
> Oleg Kostyuk (CUB-UANIC)
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
С уважением,
 Анатолий Шарифулин.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111001/323a55b5/attachment-0001.html>

From proler на gmail.com  Mon Oct  3 02:21:21 2011
From: proler на gmail.com (oleg alexeenkov)
Date: Mon, 03 Oct 2011 13:21:21 +0400
Subject: [Moscow.pm] =?utf-8?b?0JjQvdGC0LXRgNCw0YLQvtGAINC40L3QuNGG0Lg=?=
 =?utf-8?b?0LDQu9C40LfQuNGA0YPQtdGCINGB0YHRi9C70LrRgyDQvdCwINC80LDRgdGB?=
 =?utf-8?b?0LjQsi/RhdC10Yg=?=
In-Reply-To: <CAAPa60jf0jWwxPWQCqGcceS7aTEM_s8SG8Ra=y__8Bk5xKTryA@mail.gmail.com>
References: <CACEsYN5GcsxGOZLHta=yNHctdCM1=xOcGTrYA7xwe5FagsNaqQ@mail.gmail.com>
	<CANTXRvSv02aB5dy2Tvht1dRYtq5A--8PSy_XZXmaAmAMsknc1g@mail.gmail.com>
	<CAJG5KK6SOruEQGcPW6B=1NZWTxFByaEmqfu6g4a0vF74BRL7qQ@mail.gmail.com>
	<CACEsYN6QJdM3NiRVtSMT_ptZr9xotdM+G8UKL24sst4UR6OkMg@mail.gmail.com>
	<D7127F46-4E30-44F8-9A7D-17B97F8EB213@gmail.com>
	<CABXEPAG+Lb1PJTtKUvTuD_2jPzv+XLZu3EURy45yYd=0NZF1KQ@mail.gmail.com>
	<CAJG5KK5g8MN82JoS7wkDBiH9sEMjWE34kOJ7w9+iD4hg1OG=Vg@mail.gmail.com>
	<CAAPa60g8783vYsrLeK_XB__8XCtu=dOjpPFecSpM5fCP9+DCWg@mail.gmail.com>
	<BC2E1C16-47DF-4F49-A87E-93E7EF006AA6@gmail.com>
	<CAAPa60jf0jWwxPWQCqGcceS7aTEM_s8SG8Ra=y__8Bk5xKTryA@mail.gmail.com>
Message-ID: <op.v2rqxvy684v92l@proller-nb-w7.ld.yandex.ru>

Oleg Kostyuk <cub.uanic на gmail.com> писал(а) в своём письме Sat, 01 Oct  
2011 23:15:50 +0400:

UNIVERSAL::isa($a, 'HASH')

> А как же без использования ref можно безопасно "разименовать
> переменную и Получить массив или хэш", когда "не известен тип входной
> структуры"?
>
> (то что в кавычках - цитаты)
>
>
> 1 октября 2011 г. 11:43 пользователь Denis Fedoseev
> <denis.fedoseev на gmail.com> написал:
>> Это паранойя в том плане  - что если тебе нужно разименовать переменную  
>> и Получить массив или хэш - то смысла в такой проверке нет. Если тебе  
>> нужно Проверить что ссылка это массив или хэш - то тогда надо  
>> пользоваться ref eq 'ARRAY'
>>
>>
>> On Sep 30, 2011, at 11:52 PM, Oleg Kostyuk wrote:
>>
>>> Про перегрузку соглашусь, но почему использование ref eq 'ARRAY' - это
>>> паранойя? Это сплошь и рядом используется, например в том же
>>> DBIx::Class. Обоснуйте-ка, милейший!
>>>
>>> 30 сентября 2011 г. 16:51 пользователь Анатолий Шарифулин
>>> <sharifulin на gmail.com> написал:
>>>> Вместо:
>>>> @$t2 = @$t3;
>>>> обычно пишу:
>>>> $t2 = [ @$t3 ];
>>>>
>>>> Ну и: нужно быть уверенным в том, что ты разыменовываешь, если не  
>>>> уверен, то
>>>> @{ $t2 || [] };
>>>> Только не нужно быть пароноиком и использовать ref eq 'ARRAY' или
>>>> использовать перегрузку, когда не известен тип входной структуры.
>>>> Такая практика меня ещё ни разу не привела к подобным ошибкам.
>>>>
>>>> 2011/9/30 Alexander Onokhov <ccnweb на gmail.com>
>>>>>
>>>>> Да про lvalue хорошо
>>>>>
>>>>> @$t2 = (1,2,3);  # нет ошибки
>>>>>
>>>>>
>>>>> On Fri, Sep 30, 2011 at 4:42 PM, Dmitry Karpich <meettya на gmail.com>  
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> http://stackoverflow.com/questions/6419618/perl-vivification-question-while-dereferencing-undefined-array-reference
>>>>>>
>>>>>> http://stackoverflow.com/questions/2206836/why-does-perl-autovivify-in-this-case
>>>>>> stackoverflow наш друг :)
>>>>>>
>>>>>> On Sep 30, 2011, at 5:38 PM, Иван Бессарабов wrote:
>>>>>>
>>>>>> Ок. А почему в списочном контексте происходит инициализация ссылки?
>>>>>>
>>>>>> 30 сентября 2011 г. 17:32 пользователь Анатолий Шарифулин
>>>>>> <sharifulin на gmail.com> написал:
>>>>>>
>>>>>> Потому что разный контекст.
>>>>>>
>>>>>> foreach (scalar @$t1) {}
>>>>>>
>>>>>> Вот так будет идентично ифу.
>>>>>>
>>>>>>
>>>>>> 2011/9/30 Andrew Shitov <andy на shitov.ru>
>>>>>>
>>>>>> Потому что $t1 станет другим после foreach, а $t2 не станет :-)
>>>>>>
>>>>>> $ perl -E'use strict; use Data::Dumper; my $t; print Dumper($t); for
>>>>>>
>>>>>> (@$t) {}; print Dumper($t);'
>>>>>>
>>>>>> $VAR1 = undef;
>>>>>>
>>>>>> $VAR1 = [];
>>>>>>
>>>>>>
>>>>>> 2011/9/30 Иван Бессарабов <ivan на bessarabov.ru>:
>>>>>>
>>>>>> Я не могу понять из-за чего происходит такое поведение.
>>>>>>
>>>>>> Покажите, пожалуйста, кусок доки где объянено, почему так.
>>>>>>
>>>>>>
>>>>>> #!/usr/bin/perl
>>>>>>
>>>>>> use strict;
>>>>>>
>>>>>> use warnings;
>>>>>>
>>>>>> use 5.010;
>>>>>>
>>>>>> use Data::Dumper;
>>>>>>
>>>>>> my ($t1, $t2);
>>>>>>
>>>>>> foreach (@$t1) {} # почему-то не вызывает ошибку
>>>>>>
>>>>>> say Dumper $t1;
>>>>>>
>>>>>> say '' if @$t2; # вызывает ошибку, как и ожидалось
>>>>>>
>>>>>> say 'end';
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Moscow.pm mailing list
>>>>>>
>>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Andrew Shitov
>>>>>>
>>>>>> ______________________________________________________________________
>>>>>>
>>>>>> andy на shitov.ru | http://shitov.ru
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Moscow.pm mailing list
>>>>>>
>>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> С уважением,
>>>>>>
>>>>>>  Анатолий Шарифулин.
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Moscow.pm mailing list
>>>>>>
>>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Moscow.pm mailing list
>>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Moscow.pm mailing list
>>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Alexander
>>>>>
>>>>> --
>>>>> Moscow.pm mailing list
>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> С уважением,
>>>>  Анатолий Шарифулин.
>>>>
>>>> --
>>>> Moscow.pm mailing list
>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Sincerely yours,
>>> Oleg Kostyuk (CUB-UANIC)
>>> --
>>> Moscow.pm mailing list
>>> moscow-pm на pm.org | http://moscow.pm.org
>>
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>
>
>

From meettya на gmail.com  Mon Oct  3 02:42:59 2011
From: meettya на gmail.com (Dmitry Karpich)
Date: Mon, 3 Oct 2011 13:42:59 +0400
Subject: [Moscow.pm] =?utf-8?b?0JjQvdGC0LXRgNCw0YLQvtGAINC40L3QuNGG0Lg=?=
 =?utf-8?b?0LDQu9C40LfQuNGA0YPQtdGCINGB0YHRi9C70LrRgyDQvdCwINC80LDRgdGB?=
 =?utf-8?b?0LjQsi/RhdC10Yg=?=
In-Reply-To: <op.v2rqxvy684v92l@proller-nb-w7.ld.yandex.ru>
References: <CACEsYN5GcsxGOZLHta=yNHctdCM1=xOcGTrYA7xwe5FagsNaqQ@mail.gmail.com>
	<CANTXRvSv02aB5dy2Tvht1dRYtq5A--8PSy_XZXmaAmAMsknc1g@mail.gmail.com>
	<CAJG5KK6SOruEQGcPW6B=1NZWTxFByaEmqfu6g4a0vF74BRL7qQ@mail.gmail.com>
	<CACEsYN6QJdM3NiRVtSMT_ptZr9xotdM+G8UKL24sst4UR6OkMg@mail.gmail.com>
	<D7127F46-4E30-44F8-9A7D-17B97F8EB213@gmail.com>
	<CABXEPAG+Lb1PJTtKUvTuD_2jPzv+XLZu3EURy45yYd=0NZF1KQ@mail.gmail.com>
	<CAJG5KK5g8MN82JoS7wkDBiH9sEMjWE34kOJ7w9+iD4hg1OG=Vg@mail.gmail.com>
	<CAAPa60g8783vYsrLeK_XB__8XCtu=dOjpPFecSpM5fCP9+DCWg@mail.gmail.com>
	<BC2E1C16-47DF-4F49-A87E-93E7EF006AA6@gmail.com>
	<CAAPa60jf0jWwxPWQCqGcceS7aTEM_s8SG8Ra=y__8Bk5xKTryA@mail.gmail.com>
	<op.v2rqxvy684v92l@proller-nb-w7.ld.yandex.ru>
Message-ID: <C0E501BC-3A35-48EF-B101-20DAEAEB92D2@gmail.com>

Простите, но советы ваши контрреволюцией попахивают :)

http://perldoc.perl.org/UNIVERSAL.html

"instead, use reftype from Scalar::Util "

там еще много чего интересного есть, в манах-то.

Митяй.

On Oct 3, 2011, at 1:21 PM, oleg alexeenkov wrote:

> Oleg Kostyuk <cub.uanic на gmail.com> писал(а) в своём письме Sat, 01 Oct 2011 23:15:50 +0400:
> 
> UNIVERSAL::isa($a, 'HASH')
> 
>> А как же без использования ref можно безопасно "разименовать
>> переменную и Получить массив или хэш", когда "не известен тип входной
>> структуры"?
>> 
>> (то что в кавычках - цитаты)

<.. hyper mass skip ..>

>>> 
>> 
>> 
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111003/8334ecc3/attachment.html>

From cub.uanic на gmail.com  Mon Oct  3 04:20:50 2011
From: cub.uanic на gmail.com (Oleg Kostyuk)
Date: Mon, 3 Oct 2011 14:20:50 +0300
Subject: [Moscow.pm] =?utf-8?b?0JjQvdGC0LXRgNCw0YLQvtGAINC40L3QuNGG0Lg=?=
	=?utf-8?b?0LDQu9C40LfQuNGA0YPQtdGCINGB0YHRi9C70LrRgyDQvdCwINC80LA=?=
	=?utf-8?b?0YHRgdC40LIv0YXQtdGI?=
In-Reply-To: <op.v2rqxvy684v92l@proller-nb-w7.ld.yandex.ru>
References: <CACEsYN5GcsxGOZLHta=yNHctdCM1=xOcGTrYA7xwe5FagsNaqQ@mail.gmail.com>
	<CANTXRvSv02aB5dy2Tvht1dRYtq5A--8PSy_XZXmaAmAMsknc1g@mail.gmail.com>
	<CAJG5KK6SOruEQGcPW6B=1NZWTxFByaEmqfu6g4a0vF74BRL7qQ@mail.gmail.com>
	<CACEsYN6QJdM3NiRVtSMT_ptZr9xotdM+G8UKL24sst4UR6OkMg@mail.gmail.com>
	<D7127F46-4E30-44F8-9A7D-17B97F8EB213@gmail.com>
	<CABXEPAG+Lb1PJTtKUvTuD_2jPzv+XLZu3EURy45yYd=0NZF1KQ@mail.gmail.com>
	<CAJG5KK5g8MN82JoS7wkDBiH9sEMjWE34kOJ7w9+iD4hg1OG=Vg@mail.gmail.com>
	<CAAPa60g8783vYsrLeK_XB__8XCtu=dOjpPFecSpM5fCP9+DCWg@mail.gmail.com>
	<BC2E1C16-47DF-4F49-A87E-93E7EF006AA6@gmail.com>
	<CAAPa60jf0jWwxPWQCqGcceS7aTEM_s8SG8Ra=y__8Bk5xKTryA@mail.gmail.com>
	<op.v2rqxvy684v92l@proller-nb-w7.ld.yandex.ru>
Message-ID: <CAAPa60iBWciY7fAJFCS+SEkiOZy4N-8sBZd6Bb+FtCsYie+F9Q@mail.gmail.com>

Вопрос был не о том, "а каким другим способом это можно проверить".
Возможно, формулировка была не однозначна, но имелось ввиду следующее:
как же вообще можно <cite>безопасно "разименовать переменную и
Получить массив или хэш", когда "не известен тип входной
структуры"?</cite> - ведь если данные по ссылке и разыменование не
совпадут по типам, то будет сгенерировано исключение.


3 октября 2011 г. 12:21 пользователь oleg alexeenkov <proler на gmail.com> написал:
> Oleg Kostyuk <cub.uanic на gmail.com> писал(а) в своём письме Sat, 01 Oct 2011
> 23:15:50 +0400:
>
> UNIVERSAL::isa($a, 'HASH')
>
>> А как же без использования ref можно безопасно "разименовать
>> переменную и Получить массив или хэш", когда "не известен тип входной
>> структуры"?
>>
>> (то что в кавычках - цитаты)
>>
>>
>> 1 октября 2011 г. 11:43 пользователь Denis Fedoseev
>> <denis.fedoseev на gmail.com> написал:
>>>
>>> Это паранойя в том плане  - что если тебе нужно разименовать переменную и
>>> Получить массив или хэш - то смысла в такой проверке нет. Если тебе нужно
>>> Проверить что ссылка это массив или хэш - то тогда надо пользоваться ref eq
>>> 'ARRAY'
>>>
>>>
>>> On Sep 30, 2011, at 11:52 PM, Oleg Kostyuk wrote:
>>>
>>>> Про перегрузку соглашусь, но почему использование ref eq 'ARRAY' - это
>>>> паранойя? Это сплошь и рядом используется, например в том же
>>>> DBIx::Class. Обоснуйте-ка, милейший!
>>>>
>>>> 30 сентября 2011 г. 16:51 пользователь Анатолий Шарифулин
>>>> <sharifulin на gmail.com> написал:
>>>>>
>>>>> Вместо:
>>>>> @$t2 = @$t3;
>>>>> обычно пишу:
>>>>> $t2 = [ @$t3 ];
>>>>>
>>>>> Ну и: нужно быть уверенным в том, что ты разыменовываешь, если не
>>>>> уверен, то
>>>>> @{ $t2 || [] };
>>>>> Только не нужно быть пароноиком и использовать ref eq 'ARRAY' или
>>>>> использовать перегрузку, когда не известен тип входной структуры.
>>>>> Такая практика меня ещё ни разу не привела к подобным ошибкам.
>>>>>
>>>>> 2011/9/30 Alexander Onokhov <ccnweb на gmail.com>
>>>>>>
>>>>>> Да про lvalue хорошо
>>>>>>
>>>>>> @$t2 = (1,2,3);  # нет ошибки
>>>>>>
>>>>>>
>>>>>> On Fri, Sep 30, 2011 at 4:42 PM, Dmitry Karpich <meettya на gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://stackoverflow.com/questions/6419618/perl-vivification-question-while-dereferencing-undefined-array-reference
>>>>>>>
>>>>>>>
>>>>>>> http://stackoverflow.com/questions/2206836/why-does-perl-autovivify-in-this-case
>>>>>>> stackoverflow наш друг :)
>>>>>>>
>>>>>>> On Sep 30, 2011, at 5:38 PM, Иван Бессарабов wrote:
>>>>>>>
>>>>>>> Ок. А почему в списочном контексте происходит инициализация ссылки?
>>>>>>>
>>>>>>> 30 сентября 2011 г. 17:32 пользователь Анатолий Шарифулин
>>>>>>> <sharifulin на gmail.com> написал:
>>>>>>>
>>>>>>> Потому что разный контекст.
>>>>>>>
>>>>>>> foreach (scalar @$t1) {}
>>>>>>>
>>>>>>> Вот так будет идентично ифу.
>>>>>>>
>>>>>>>
>>>>>>> 2011/9/30 Andrew Shitov <andy на shitov.ru>
>>>>>>>
>>>>>>> Потому что $t1 станет другим после foreach, а $t2 не станет :-)
>>>>>>>
>>>>>>> $ perl -E'use strict; use Data::Dumper; my $t; print Dumper($t); for
>>>>>>>
>>>>>>> (@$t) {}; print Dumper($t);'
>>>>>>>
>>>>>>> $VAR1 = undef;
>>>>>>>
>>>>>>> $VAR1 = [];
>>>>>>>
>>>>>>>
>>>>>>> 2011/9/30 Иван Бессарабов <ivan на bessarabov.ru>:
>>>>>>>
>>>>>>> Я не могу понять из-за чего происходит такое поведение.
>>>>>>>
>>>>>>> Покажите, пожалуйста, кусок доки где объянено, почему так.
>>>>>>>
>>>>>>>
>>>>>>> #!/usr/bin/perl
>>>>>>>
>>>>>>> use strict;
>>>>>>>
>>>>>>> use warnings;
>>>>>>>
>>>>>>> use 5.010;
>>>>>>>
>>>>>>> use Data::Dumper;
>>>>>>>
>>>>>>> my ($t1, $t2);
>>>>>>>
>>>>>>> foreach (@$t1) {} # почему-то не вызывает ошибку
>>>>>>>
>>>>>>> say Dumper $t1;
>>>>>>>
>>>>>>> say '' if @$t2; # вызывает ошибку, как и ожидалось
>>>>>>>
>>>>>>> say 'end';
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Moscow.pm mailing list
>>>>>>>
>>>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Andrew Shitov
>>>>>>>
>>>>>>>
>>>>>>> ______________________________________________________________________
>>>>>>>
>>>>>>> andy на shitov.ru | http://shitov.ru
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Moscow.pm mailing list
>>>>>>>
>>>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> С уважением,
>>>>>>>
>>>>>>>  Анатолий Шарифулин.
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Moscow.pm mailing list
>>>>>>>
>>>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Moscow.pm mailing list
>>>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Moscow.pm mailing list
>>>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Alexander
>>>>>>
>>>>>> --
>>>>>> Moscow.pm mailing list
>>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> С уважением,
>>>>>  Анатолий Шарифулин.
>>>>>
>>>>> --
>>>>> Moscow.pm mailing list
>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sincerely yours,
>>>> Oleg Kostyuk (CUB-UANIC)
>>>> --
>>>> Moscow.pm mailing list
>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>
>>> --
>>> Moscow.pm mailing list
>>> moscow-pm на pm.org | http://moscow.pm.org
>>>
>>
>>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
Sincerely yours,
Oleg Kostyuk (CUB-UANIC)

From sharifulin на gmail.com  Mon Oct  3 04:31:11 2011
From: sharifulin на gmail.com (=?KOI8-R?B?4c7B1M/Mycog+8HSycbVzMnO?=)
Date: Mon, 3 Oct 2011 15:31:11 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?6c7UxdLB1M/SIMnOycPJwczJ2snS1cXUINPT2czL?=
	=?koi8-r?b?1SDOwSDNwdPTydcvyMXb?=
In-Reply-To: <CAAPa60iBWciY7fAJFCS+SEkiOZy4N-8sBZd6Bb+FtCsYie+F9Q@mail.gmail.com>
References: <CACEsYN5GcsxGOZLHta=yNHctdCM1=xOcGTrYA7xwe5FagsNaqQ@mail.gmail.com>
	<CANTXRvSv02aB5dy2Tvht1dRYtq5A--8PSy_XZXmaAmAMsknc1g@mail.gmail.com>
	<CAJG5KK6SOruEQGcPW6B=1NZWTxFByaEmqfu6g4a0vF74BRL7qQ@mail.gmail.com>
	<CACEsYN6QJdM3NiRVtSMT_ptZr9xotdM+G8UKL24sst4UR6OkMg@mail.gmail.com>
	<D7127F46-4E30-44F8-9A7D-17B97F8EB213@gmail.com>
	<CABXEPAG+Lb1PJTtKUvTuD_2jPzv+XLZu3EURy45yYd=0NZF1KQ@mail.gmail.com>
	<CAJG5KK5g8MN82JoS7wkDBiH9sEMjWE34kOJ7w9+iD4hg1OG=Vg@mail.gmail.com>
	<CAAPa60g8783vYsrLeK_XB__8XCtu=dOjpPFecSpM5fCP9+DCWg@mail.gmail.com>
	<BC2E1C16-47DF-4F49-A87E-93E7EF006AA6@gmail.com>
	<CAAPa60jf0jWwxPWQCqGcceS7aTEM_s8SG8Ra=y__8Bk5xKTryA@mail.gmail.com>
	<op.v2rqxvy684v92l@proller-nb-w7.ld.yandex.ru>
	<CAAPa60iBWciY7fAJFCS+SEkiOZy4N-8sBZd6Bb+FtCsYie+F9Q@mail.gmail.com>
Message-ID: <CAJG5KK50-Spd5Mj0XisYutyEyuHNKDygu4QN66EdNX_RAcPM1w@mail.gmail.com>

Олег, какой Вы настырный :-)

Специфицируйте входные данные и вам не придётся писать лишние проверки.
Если в сабу приходит только ссылка на массив, то не стоит писать код: ref eq
'ARRAY'
Это условие всегда будет тру. Я это имел в виду.


2011/10/3 Oleg Kostyuk <cub.uanic на gmail.com>

> Вопрос был не о том, "а каким другим способом это можно проверить".
> Возможно, формулировка была не однозначна, но имелось ввиду следующее:
> как же вообще можно <cite>безопасно "разименовать переменную и
> Получить массив или хэш", когда "не известен тип входной
> структуры"?</cite> - ведь если данные по ссылке и разыменование не
> совпадут по типам, то будет сгенерировано исключение.
>
>
> 3 октября 2011 г. 12:21 пользователь oleg alexeenkov <proler на gmail.com>
> написал:
> > Oleg Kostyuk <cub.uanic на gmail.com> писал(а) в своём письме Sat, 01 Oct
> 2011
> > 23:15:50 +0400:
> >
> > UNIVERSAL::isa($a, 'HASH')
> >
> >> А как же без использования ref можно безопасно "разименовать
> >> переменную и Получить массив или хэш", когда "не известен тип входной
> >> структуры"?
> >>
> >> (то что в кавычках - цитаты)
> >>
> >>
> >> 1 октября 2011 г. 11:43 пользователь Denis Fedoseev
> >> <denis.fedoseev на gmail.com> написал:
> >>>
> >>> Это паранойя в том плане  - что если тебе нужно разименовать переменную
> и
> >>> Получить массив или хэш - то смысла в такой проверке нет. Если тебе
> нужно
> >>> Проверить что ссылка это массив или хэш - то тогда надо пользоваться
> ref eq
> >>> 'ARRAY'
> >>>
> >>>
> >>> On Sep 30, 2011, at 11:52 PM, Oleg Kostyuk wrote:
> >>>
> >>>> Про перегрузку соглашусь, но почему использование ref eq 'ARRAY' - это
> >>>> паранойя? Это сплошь и рядом используется, например в том же
> >>>> DBIx::Class. Обоснуйте-ка, милейший!
> >>>>
> >>>> 30 сентября 2011 г. 16:51 пользователь Анатолий Шарифулин
> >>>> <sharifulin на gmail.com> написал:
> >>>>>
> >>>>> Вместо:
> >>>>> @$t2 = @$t3;
> >>>>> обычно пишу:
> >>>>> $t2 = [ @$t3 ];
> >>>>>
> >>>>> Ну и: нужно быть уверенным в том, что ты разыменовываешь, если не
> >>>>> уверен, то
> >>>>> @{ $t2 || [] };
> >>>>> Только не нужно быть пароноиком и использовать ref eq 'ARRAY' или
> >>>>> использовать перегрузку, когда не известен тип входной структуры.
> >>>>> Такая практика меня ещё ни разу не привела к подобным ошибкам.
> >>>>>
> >>>>> 2011/9/30 Alexander Onokhov <ccnweb на gmail.com>
> >>>>>>
> >>>>>> Да про lvalue хорошо
> >>>>>>
> >>>>>> @$t2 = (1,2,3);  # нет ошибки
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Sep 30, 2011 at 4:42 PM, Dmitry Karpich <meettya на gmail.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> http://stackoverflow.com/questions/6419618/perl-vivification-question-while-dereferencing-undefined-array-reference
> >>>>>>>
> >>>>>>>
> >>>>>>>
> http://stackoverflow.com/questions/2206836/why-does-perl-autovivify-in-this-case
> >>>>>>> stackoverflow наш друг :)
> >>>>>>>
> >>>>>>> On Sep 30, 2011, at 5:38 PM, Иван Бессарабов wrote:
> >>>>>>>
> >>>>>>> Ок. А почему в списочном контексте происходит инициализация ссылки?
> >>>>>>>
> >>>>>>> 30 сентября 2011 г. 17:32 пользователь Анатолий Шарифулин
> >>>>>>> <sharifulin на gmail.com> написал:
> >>>>>>>
> >>>>>>> Потому что разный контекст.
> >>>>>>>
> >>>>>>> foreach (scalar @$t1) {}
> >>>>>>>
> >>>>>>> Вот так будет идентично ифу.
> >>>>>>>
> >>>>>>>
> >>>>>>> 2011/9/30 Andrew Shitov <andy на shitov.ru>
> >>>>>>>
> >>>>>>> Потому что $t1 станет другим после foreach, а $t2 не станет :-)
> >>>>>>>
> >>>>>>> $ perl -E'use strict; use Data::Dumper; my $t; print Dumper($t);
> for
> >>>>>>>
> >>>>>>> (@$t) {}; print Dumper($t);'
> >>>>>>>
> >>>>>>> $VAR1 = undef;
> >>>>>>>
> >>>>>>> $VAR1 = [];
> >>>>>>>
> >>>>>>>
> >>>>>>> 2011/9/30 Иван Бессарабов <ivan на bessarabov.ru>:
> >>>>>>>
> >>>>>>> Я не могу понять из-за чего происходит такое поведение.
> >>>>>>>
> >>>>>>> Покажите, пожалуйста, кусок доки где объянено, почему так.
> >>>>>>>
> >>>>>>>
> >>>>>>> #!/usr/bin/perl
> >>>>>>>
> >>>>>>> use strict;
> >>>>>>>
> >>>>>>> use warnings;
> >>>>>>>
> >>>>>>> use 5.010;
> >>>>>>>
> >>>>>>> use Data::Dumper;
> >>>>>>>
> >>>>>>> my ($t1, $t2);
> >>>>>>>
> >>>>>>> foreach (@$t1) {} # почему-то не вызывает ошибку
> >>>>>>>
> >>>>>>> say Dumper $t1;
> >>>>>>>
> >>>>>>> say '' if @$t2; # вызывает ошибку, как и ожидалось
> >>>>>>>
> >>>>>>> say 'end';
> >>>>>>>
> >>>>>>> --
> >>>>>>>
> >>>>>>> Moscow.pm mailing list
> >>>>>>>
> >>>>>>> moscow-pm на pm.org | http://moscow.pm.org
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>>
> >>>>>>> Andrew Shitov
> >>>>>>>
> >>>>>>>
> >>>>>>>
> ______________________________________________________________________
> >>>>>>>
> >>>>>>> andy на shitov.ru | http://shitov.ru
> >>>>>>>
> >>>>>>> --
> >>>>>>>
> >>>>>>> Moscow.pm mailing list
> >>>>>>>
> >>>>>>> moscow-pm на pm.org | http://moscow.pm.org
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>>
> >>>>>>> С уважением,
> >>>>>>>
> >>>>>>>  Анатолий Шарифулин.
> >>>>>>>
> >>>>>>> --
> >>>>>>>
> >>>>>>> Moscow.pm mailing list
> >>>>>>>
> >>>>>>> moscow-pm на pm.org | http://moscow.pm.org
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Moscow.pm mailing list
> >>>>>>> moscow-pm на pm.org | http://moscow.pm.org
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Moscow.pm mailing list
> >>>>>>> moscow-pm на pm.org | http://moscow.pm.org
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Alexander
> >>>>>>
> >>>>>> --
> >>>>>> Moscow.pm mailing list
> >>>>>> moscow-pm на pm.org | http://moscow.pm.org
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> С уважением,
> >>>>>  Анатолий Шарифулин.
> >>>>>
> >>>>> --
> >>>>> Moscow.pm mailing list
> >>>>> moscow-pm на pm.org | http://moscow.pm.org
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Sincerely yours,
> >>>> Oleg Kostyuk (CUB-UANIC)
> >>>> --
> >>>> Moscow.pm mailing list
> >>>> moscow-pm на pm.org | http://moscow.pm.org
> >>>
> >>> --
> >>> Moscow.pm mailing list
> >>> moscow-pm на pm.org | http://moscow.pm.org
> >>>
> >>
> >>
> > --
> > Moscow.pm mailing list
> > moscow-pm на pm.org | http://moscow.pm.org
> >
>
>
>
> --
> Sincerely yours,
> Oleg Kostyuk (CUB-UANIC)
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
С уважением,
 Анатолий Шарифулин.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111003/8986a507/attachment.html>

From cub.uanic на gmail.com  Mon Oct  3 04:51:01 2011
From: cub.uanic на gmail.com (Oleg Kostyuk)
Date: Mon, 3 Oct 2011 14:51:01 +0300
Subject: [Moscow.pm] =?utf-8?b?0JjQvdGC0LXRgNCw0YLQvtGAINC40L3QuNGG0Lg=?=
	=?utf-8?b?0LDQu9C40LfQuNGA0YPQtdGCINGB0YHRi9C70LrRgyDQvdCwINC80LA=?=
	=?utf-8?b?0YHRgdC40LIv0YXQtdGI?=
In-Reply-To: <CAJG5KK50-Spd5Mj0XisYutyEyuHNKDygu4QN66EdNX_RAcPM1w@mail.gmail.com>
References: <CACEsYN5GcsxGOZLHta=yNHctdCM1=xOcGTrYA7xwe5FagsNaqQ@mail.gmail.com>
	<CANTXRvSv02aB5dy2Tvht1dRYtq5A--8PSy_XZXmaAmAMsknc1g@mail.gmail.com>
	<CAJG5KK6SOruEQGcPW6B=1NZWTxFByaEmqfu6g4a0vF74BRL7qQ@mail.gmail.com>
	<CACEsYN6QJdM3NiRVtSMT_ptZr9xotdM+G8UKL24sst4UR6OkMg@mail.gmail.com>
	<D7127F46-4E30-44F8-9A7D-17B97F8EB213@gmail.com>
	<CABXEPAG+Lb1PJTtKUvTuD_2jPzv+XLZu3EURy45yYd=0NZF1KQ@mail.gmail.com>
	<CAJG5KK5g8MN82JoS7wkDBiH9sEMjWE34kOJ7w9+iD4hg1OG=Vg@mail.gmail.com>
	<CAAPa60g8783vYsrLeK_XB__8XCtu=dOjpPFecSpM5fCP9+DCWg@mail.gmail.com>
	<BC2E1C16-47DF-4F49-A87E-93E7EF006AA6@gmail.com>
	<CAAPa60jf0jWwxPWQCqGcceS7aTEM_s8SG8Ra=y__8Bk5xKTryA@mail.gmail.com>
	<op.v2rqxvy684v92l@proller-nb-w7.ld.yandex.ru>
	<CAAPa60iBWciY7fAJFCS+SEkiOZy4N-8sBZd6Bb+FtCsYie+F9Q@mail.gmail.com>
	<CAJG5KK50-Spd5Mj0XisYutyEyuHNKDygu4QN66EdNX_RAcPM1w@mail.gmail.com>
Message-ID: <CAAPa60jZ2=yUmzeQd=U1ye=3kPxEbNkDJp8s47uC5rcNONxF5g@mail.gmail.com>

3 октября 2011 г. 14:31 пользователь Анатолий Шарифулин
<sharifulin на gmail.com> написал:
> Олег, какой Вы настырный :-)
Нет же, что вы. Просто человек неверно понял мои слова - я внёс
ясность. Никакой настырности и рядом не валялось.


> Специфицируйте входные данные и вам не придётся писать лишние проверки.
Пожалуйста, вот вам спецификация:
http://search.cpan.org/dist/DBIx-Class/lib/DBIx/Class/ResultSet.pm#find
Или ещё лучше: http://search.cpan.org/dist/DBIx-Class/lib/DBIx/Class/ResultSet.pm#order_by

Если лень ходить по ссылкам - вот нужные куски:

  find
    Arguments: \%columns_values | @pk_values, \%attrs?
    Return Value: $row_object | undef

  order_by
    Value: ( $order_by | \@order_by | \%order_by )

Я бы посмотрел, как будет делаться разыменование без проверок. И
только не надо говорить, что "спека кривая" и "так только идиоты
пишут" :) Потому что это работает, и работает классно и удобно.


> Если в сабу приходит только ссылка на массив, то не стоит писать код:
>  ref eq'ARRAY'
> Это условие всегда будет тру. Я это имел в виду.
Ну, это ж совсем другое дело. Получается, ваши слова тоже были совсем
не однозначны. С кем не бывает - имел ввиду одно, сказал другое.
Теперь всё понятно, спасибо за разъяснения.


> 2011/10/3 Oleg Kostyuk <cub.uanic на gmail.com>
>>
>> Вопрос был не о том, "а каким другим способом это можно проверить".
>> Возможно, формулировка была не однозначна, но имелось ввиду следующее:
>> как же вообще можно <cite>безопасно "разименовать переменную и
>> Получить массив или хэш", когда "не известен тип входной
>> структуры"?</cite> - ведь если данные по ссылке и разыменование не
>> совпадут по типам, то будет сгенерировано исключение.
>>
>>
>> 3 октября 2011 г. 12:21 пользователь oleg alexeenkov <proler на gmail.com>
>> написал:
>> > Oleg Kostyuk <cub.uanic на gmail.com> писал(а) в своём письме Sat, 01 Oct
>> > 2011
>> > 23:15:50 +0400:
>> >
>> > UNIVERSAL::isa($a, 'HASH')
>> >
>> >> А как же без использования ref можно безопасно "разименовать
>> >> переменную и Получить массив или хэш", когда "не известен тип входной
>> >> структуры"?
>> >>
>> >> (то что в кавычках - цитаты)
>> >>
>> >>
>> >> 1 октября 2011 г. 11:43 пользователь Denis Fedoseev
>> >> <denis.fedoseev на gmail.com> написал:
>> >>>
>> >>> Это паранойя в том плане  - что если тебе нужно разименовать
>> >>> переменную и
>> >>> Получить массив или хэш - то смысла в такой проверке нет. Если тебе
>> >>> нужно
>> >>> Проверить что ссылка это массив или хэш - то тогда надо пользоваться
>> >>> ref eq
>> >>> 'ARRAY'
>> >>>
>> >>>
>> >>> On Sep 30, 2011, at 11:52 PM, Oleg Kostyuk wrote:
>> >>>
>> >>>> Про перегрузку соглашусь, но почему использование ref eq 'ARRAY' -
>> >>>> это
>> >>>> паранойя? Это сплошь и рядом используется, например в том же
>> >>>> DBIx::Class. Обоснуйте-ка, милейший!
>> >>>>
>> >>>> 30 сентября 2011 г. 16:51 пользователь Анатолий Шарифулин
>> >>>> <sharifulin на gmail.com> написал:
>> >>>>>
>> >>>>> Вместо:
>> >>>>> @$t2 = @$t3;
>> >>>>> обычно пишу:
>> >>>>> $t2 = [ @$t3 ];
>> >>>>>
>> >>>>> Ну и: нужно быть уверенным в том, что ты разыменовываешь, если не
>> >>>>> уверен, то
>> >>>>> @{ $t2 || [] };
>> >>>>> Только не нужно быть пароноиком и использовать ref eq 'ARRAY' или
>> >>>>> использовать перегрузку, когда не известен тип входной структуры.
>> >>>>> Такая практика меня ещё ни разу не привела к подобным ошибкам.
>> >>>>>
>> >>>>> 2011/9/30 Alexander Onokhov <ccnweb на gmail.com>
>> >>>>>>
>> >>>>>> Да про lvalue хорошо
>> >>>>>>
>> >>>>>> @$t2 = (1,2,3);  # нет ошибки
>> >>>>>>
>> >>>>>>
>> >>>>>> On Fri, Sep 30, 2011 at 4:42 PM, Dmitry Karpich <meettya на gmail.com>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> http://stackoverflow.com/questions/6419618/perl-vivification-question-while-dereferencing-undefined-array-reference
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> http://stackoverflow.com/questions/2206836/why-does-perl-autovivify-in-this-case
>> >>>>>>> stackoverflow наш друг :)
>> >>>>>>>
>> >>>>>>> On Sep 30, 2011, at 5:38 PM, Иван Бессарабов wrote:
>> >>>>>>>
>> >>>>>>> Ок. А почему в списочном контексте происходит инициализация
>> >>>>>>> ссылки?
>> >>>>>>>
>> >>>>>>> 30 сентября 2011 г. 17:32 пользователь Анатолий Шарифулин
>> >>>>>>> <sharifulin на gmail.com> написал:
>> >>>>>>>
>> >>>>>>> Потому что разный контекст.
>> >>>>>>>
>> >>>>>>> foreach (scalar @$t1) {}
>> >>>>>>>
>> >>>>>>> Вот так будет идентично ифу.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 2011/9/30 Andrew Shitov <andy на shitov.ru>
>> >>>>>>>
>> >>>>>>> Потому что $t1 станет другим после foreach, а $t2 не станет :-)
>> >>>>>>>
>> >>>>>>> $ perl -E'use strict; use Data::Dumper; my $t; print Dumper($t);
>> >>>>>>> for
>> >>>>>>>
>> >>>>>>> (@$t) {}; print Dumper($t);'
>> >>>>>>>
>> >>>>>>> $VAR1 = undef;
>> >>>>>>>
>> >>>>>>> $VAR1 = [];
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 2011/9/30 Иван Бессарабов <ivan на bessarabov.ru>:
>> >>>>>>>
>> >>>>>>> Я не могу понять из-за чего происходит такое поведение.
>> >>>>>>>
>> >>>>>>> Покажите, пожалуйста, кусок доки где объянено, почему так.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> #!/usr/bin/perl
>> >>>>>>>
>> >>>>>>> use strict;
>> >>>>>>>
>> >>>>>>> use warnings;
>> >>>>>>>
>> >>>>>>> use 5.010;
>> >>>>>>>
>> >>>>>>> use Data::Dumper;
>> >>>>>>>
>> >>>>>>> my ($t1, $t2);
>> >>>>>>>
>> >>>>>>> foreach (@$t1) {} # почему-то не вызывает ошибку
>> >>>>>>>
>> >>>>>>> say Dumper $t1;
>> >>>>>>>
>> >>>>>>> say '' if @$t2; # вызывает ошибку, как и ожидалось
>> >>>>>>>
>> >>>>>>> say 'end';
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>>
>> >>>>>>> Moscow.pm mailing list
>> >>>>>>>
>> >>>>>>> moscow-pm на pm.org | http://moscow.pm.org
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>>
>> >>>>>>> Andrew Shitov
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> ______________________________________________________________________
>> >>>>>>>
>> >>>>>>> andy на shitov.ru | http://shitov.ru
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>>
>> >>>>>>> Moscow.pm mailing list
>> >>>>>>>
>> >>>>>>> moscow-pm на pm.org | http://moscow.pm.org
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>>
>> >>>>>>> С уважением,
>> >>>>>>>
>> >>>>>>>  Анатолий Шарифулин.
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>>
>> >>>>>>> Moscow.pm mailing list
>> >>>>>>>
>> >>>>>>> moscow-pm на pm.org | http://moscow.pm.org
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> Moscow.pm mailing list
>> >>>>>>> moscow-pm на pm.org | http://moscow.pm.org
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> Moscow.pm mailing list
>> >>>>>>> moscow-pm на pm.org | http://moscow.pm.org
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>> Alexander
>> >>>>>>
>> >>>>>> --
>> >>>>>> Moscow.pm mailing list
>> >>>>>> moscow-pm на pm.org | http://moscow.pm.org
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> С уважением,
>> >>>>>  Анатолий Шарифулин.
>> >>>>>
>> >>>>> --
>> >>>>> Moscow.pm mailing list
>> >>>>> moscow-pm на pm.org | http://moscow.pm.org
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Sincerely yours,
>> >>>> Oleg Kostyuk (CUB-UANIC)
>> >>>> --
>> >>>> Moscow.pm mailing list
>> >>>> moscow-pm на pm.org | http://moscow.pm.org
>> >>>
>> >>> --
>> >>> Moscow.pm mailing list
>> >>> moscow-pm на pm.org | http://moscow.pm.org
>> >>>
>> >>
>> >>
>> > --
>> > Moscow.pm mailing list
>> > moscow-pm на pm.org | http://moscow.pm.org
>> >
>>
>>
>>
>> --
>> Sincerely yours,
>> Oleg Kostyuk (CUB-UANIC)
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>
>
>
> --
> С уважением,
>  Анатолий Шарифулин.
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>



-- 
Sincerely yours,
Oleg Kostyuk (CUB-UANIC)

From sharifulin на gmail.com  Mon Oct  3 05:15:33 2011
From: sharifulin на gmail.com (=?KOI8-R?B?4c7B1M/Mycog+8HSycbVzMnO?=)
Date: Mon, 3 Oct 2011 16:15:33 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?6c7UxdLB1M/SIMnOycPJwczJ2snS1cXUINPT2czL?=
	=?koi8-r?b?1SDOwSDNwdPTydcvyMXb?=
In-Reply-To: <CAAPa60jZ2=yUmzeQd=U1ye=3kPxEbNkDJp8s47uC5rcNONxF5g@mail.gmail.com>
References: <CACEsYN5GcsxGOZLHta=yNHctdCM1=xOcGTrYA7xwe5FagsNaqQ@mail.gmail.com>
	<CANTXRvSv02aB5dy2Tvht1dRYtq5A--8PSy_XZXmaAmAMsknc1g@mail.gmail.com>
	<CAJG5KK6SOruEQGcPW6B=1NZWTxFByaEmqfu6g4a0vF74BRL7qQ@mail.gmail.com>
	<CACEsYN6QJdM3NiRVtSMT_ptZr9xotdM+G8UKL24sst4UR6OkMg@mail.gmail.com>
	<D7127F46-4E30-44F8-9A7D-17B97F8EB213@gmail.com>
	<CABXEPAG+Lb1PJTtKUvTuD_2jPzv+XLZu3EURy45yYd=0NZF1KQ@mail.gmail.com>
	<CAJG5KK5g8MN82JoS7wkDBiH9sEMjWE34kOJ7w9+iD4hg1OG=Vg@mail.gmail.com>
	<CAAPa60g8783vYsrLeK_XB__8XCtu=dOjpPFecSpM5fCP9+DCWg@mail.gmail.com>
	<BC2E1C16-47DF-4F49-A87E-93E7EF006AA6@gmail.com>
	<CAAPa60jf0jWwxPWQCqGcceS7aTEM_s8SG8Ra=y__8Bk5xKTryA@mail.gmail.com>
	<op.v2rqxvy684v92l@proller-nb-w7.ld.yandex.ru>
	<CAAPa60iBWciY7fAJFCS+SEkiOZy4N-8sBZd6Bb+FtCsYie+F9Q@mail.gmail.com>
	<CAJG5KK50-Spd5Mj0XisYutyEyuHNKDygu4QN66EdNX_RAcPM1w@mail.gmail.com>
	<CAAPa60jZ2=yUmzeQd=U1ye=3kPxEbNkDJp8s47uC5rcNONxF5g@mail.gmail.com>
Message-ID: <CAJG5KK6X9xgO+ZuUXSKr3TkCgDmJXnJWh05vWxpVCq9xkwHhSg@mail.gmail.com>

2011/10/3 Oleg Kostyuk <cub.uanic на gmail.com>

> Я бы посмотрел, как будет делаться разыменование без проверок. И
> только не надо говорить, что "спека кривая" и "так только идиоты
> пишут" :) Потому что это работает, и работает классно и удобно.
>


Я не пытался это утверждать, не так часто пишется код типа DBIx::Class)
Даа в сообщение не верно выразился, бывает :)


-- 
С уважением,
 Анатолий Шарифулин.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111003/6be11dcc/attachment.html>

From mi на ya.ru  Mon Oct 10 10:56:24 2011
From: mi на ya.ru (Nikolay Mishin)
Date: Mon, 10 Oct 2011 21:56:24 +0400
Subject: [Moscow.pm] =?koi8-r?b?ydogyNzbwSDXIM3B09PJ1z8=?=
In-Reply-To: <CAJG5KK6X9xgO+ZuUXSKr3TkCgDmJXnJWh05vWxpVCq9xkwHhSg@mail.gmail.com>
References: <CACEsYN5GcsxGOZLHta=yNHctdCM1=xOcGTrYA7xwe5FagsNaqQ@mail.gmail.com>
	<CANTXRvSv02aB5dy2Tvht1dRYtq5A--8PSy_XZXmaAmAMsknc1g@mail.gmail.com>
	<CAJG5KK6SOruEQGcPW6B=1NZWTxFByaEmqfu6g4a0vF74BRL7qQ@mail.gmail.com>
	<CACEsYN6QJdM3NiRVtSMT_ptZr9xotdM+G8UKL24sst4UR6OkMg@mail.gmail.com>
	<D7127F46-4E30-44F8-9A7D-17B97F8EB213@gmail.com>
	<CABXEPAG+Lb1PJTtKUvTuD_2jPzv+XLZu3EURy45yYd=0NZF1KQ@mail.gmail.com>
	<CAJG5KK5g8MN82JoS7wkDBiH9sEMjWE34kOJ7w9+iD4hg1OG=Vg@mail.gmail.com>
	<CAAPa60g8783vYsrLeK_XB__8XCtu=dOjpPFecSpM5fCP9+DCWg@mail.gmail.com>
	<BC2E1C16-47DF-4F49-A87E-93E7EF006AA6@gmail.com>
	<CAAPa60jf0jWwxPWQCqGcceS7aTEM_s8SG8Ra=y__8Bk5xKTryA@mail.gmail.com>
	<op.v2rqxvy684v92l@proller-nb-w7.ld.yandex.ru>
	<CAAPa60iBWciY7fAJFCS+SEkiOZy4N-8sBZd6Bb+FtCsYie+F9Q@mail.gmail.com>
	<CAJG5KK50-Spd5Mj0XisYutyEyuHNKDygu4QN66EdNX_RAcPM1w@mail.gmail.com>
	<CAAPa60jZ2=yUmzeQd=U1ye=3kPxEbNkDJp8s47uC5rcNONxF5g@mail.gmail.com>
	<CAJG5KK6X9xgO+ZuUXSKr3TkCgDmJXnJWh05vWxpVCq9xkwHhSg@mail.gmail.com>
Message-ID: <208111318269384@web70.yandex.ru>

Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111010/044f0558/attachment.html>

From isage на aumi.ru  Mon Oct 10 11:04:31 2011
From: isage на aumi.ru (iSage)
Date: Mon, 10 Oct 2011 21:04:31 +0300
Subject: [Moscow.pm] =?utf-8?b?0LjQtyDRhdGN0YjQsCDQsiDQvNCw0YHRgdC40LI/?=
In-Reply-To: <208111318269384@web70.yandex.ru>
References: <CACEsYN5GcsxGOZLHta=yNHctdCM1=xOcGTrYA7xwe5FagsNaqQ@mail.gmail.com>
	<CANTXRvSv02aB5dy2Tvht1dRYtq5A--8PSy_XZXmaAmAMsknc1g@mail.gmail.com>
	<CAJG5KK6SOruEQGcPW6B=1NZWTxFByaEmqfu6g4a0vF74BRL7qQ@mail.gmail.com>
	<CACEsYN6QJdM3NiRVtSMT_ptZr9xotdM+G8UKL24sst4UR6OkMg@mail.gmail.com>
	<D7127F46-4E30-44F8-9A7D-17B97F8EB213@gmail.com>
	<CABXEPAG+Lb1PJTtKUvTuD_2jPzv+XLZu3EURy45yYd=0NZF1KQ@mail.gmail.com>
	<CAJG5KK5g8MN82JoS7wkDBiH9sEMjWE34kOJ7w9+iD4hg1OG=Vg@mail.gmail.com>
	<CAAPa60g8783vYsrLeK_XB__8XCtu=dOjpPFecSpM5fCP9+DCWg@mail.gmail.com>
	<BC2E1C16-47DF-4F49-A87E-93E7EF006AA6@gmail.com>
	<CAAPa60jf0jWwxPWQCqGcceS7aTEM_s8SG8Ra=y__8Bk5xKTryA@mail.gmail.com>
	<op.v2rqxvy684v92l@proller-nb-w7.ld.yandex.ru>
	<CAAPa60iBWciY7fAJFCS+SEkiOZy4N-8sBZd6Bb+FtCsYie+F9Q@mail.gmail.com>
	<CAJG5KK50-Spd5Mj0XisYutyEyuHNKDygu4QN66EdNX_RAcPM1w@mail.gmail.com>
	<CAAPa60jZ2=yUmzeQd=U1ye=3kPxEbNkDJp8s47uC5rcNONxF5g@mail.gmail.com>
	<CAJG5KK6X9xgO+ZuUXSKr3TkCgDmJXnJWh05vWxpVCq9xkwHhSg@mail.gmail.com>
	<208111318269384@web70.yandex.ru>
Message-ID: <c41f6f99ada71dd9361fbb1818e02c54@aumi.ru>



my @chunks=sort keys %{$ref_chunk}; 

не? 

On Mon, 10 Oct 2011
21:56:24 +0400, Nikolay Mishin  wrote:  
Mosow-pm, люди, привет 

я
никак не пойму - можно ли сделать преобразование ключей хэша в массив в
1 строку с map , например 

 my @chunks; 
 for my $chunk ( sort keys
%{$ref_chunk} ) { 
 push @chunks, $chunk; 
 }  

всю голову себе сломал

--
Nikolay Mishin  

 
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111010/75414852/attachment.html>

From andrei.protasovitski на gmail.com  Mon Oct 10 11:26:18 2011
From: andrei.protasovitski на gmail.com (Andrei)
Date: Mon, 10 Oct 2011 20:26:18 +0200
Subject: [Moscow.pm] =?utf-8?b?0LjQtyDRhdGN0YjQsCDQsiDQvNCw0YHRgdC40LI/?=
In-Reply-To: <c41f6f99ada71dd9361fbb1818e02c54@aumi.ru>
References: <CACEsYN5GcsxGOZLHta=yNHctdCM1=xOcGTrYA7xwe5FagsNaqQ@mail.gmail.com>
	<CANTXRvSv02aB5dy2Tvht1dRYtq5A--8PSy_XZXmaAmAMsknc1g@mail.gmail.com>
	<CAJG5KK6SOruEQGcPW6B=1NZWTxFByaEmqfu6g4a0vF74BRL7qQ@mail.gmail.com>
	<CACEsYN6QJdM3NiRVtSMT_ptZr9xotdM+G8UKL24sst4UR6OkMg@mail.gmail.com>
	<D7127F46-4E30-44F8-9A7D-17B97F8EB213@gmail.com>
	<CABXEPAG+Lb1PJTtKUvTuD_2jPzv+XLZu3EURy45yYd=0NZF1KQ@mail.gmail.com>
	<CAJG5KK5g8MN82JoS7wkDBiH9sEMjWE34kOJ7w9+iD4hg1OG=Vg@mail.gmail.com>
	<CAAPa60g8783vYsrLeK_XB__8XCtu=dOjpPFecSpM5fCP9+DCWg@mail.gmail.com>
	<BC2E1C16-47DF-4F49-A87E-93E7EF006AA6@gmail.com>
	<CAAPa60jf0jWwxPWQCqGcceS7aTEM_s8SG8Ra=y__8Bk5xKTryA@mail.gmail.com>
	<op.v2rqxvy684v92l@proller-nb-w7.ld.yandex.ru>
	<CAAPa60iBWciY7fAJFCS+SEkiOZy4N-8sBZd6Bb+FtCsYie+F9Q@mail.gmail.com>
	<CAJG5KK50-Spd5Mj0XisYutyEyuHNKDygu4QN66EdNX_RAcPM1w@mail.gmail.com>
	<CAAPa60jZ2=yUmzeQd=U1ye=3kPxEbNkDJp8s47uC5rcNONxF5g@mail.gmail.com>
	<CAJG5KK6X9xgO+ZuUXSKr3TkCgDmJXnJWh05vWxpVCq9xkwHhSg@mail.gmail.com>
	<208111318269384@web70.yandex.ru>
	<c41f6f99ada71dd9361fbb1818e02c54@aumi.ru>
Message-ID: <CANVWn7FyVkd+X6vfF9h-FQrnSDsr1J0Qbx60X+gyu-9ip6_AMA@mail.gmail.com>

Да можно даже и без sort.
10.10.2011 20:03 пользователь "iSage" <isage на aumi.ru> написал:

> my @chunks=sort keys %{$ref_chunk};
>
> не?
>
> On Mon, 10 Oct 2011 21:56:24 +0400, Nikolay Mishin <mi на ya.ru> wrote:
>
> Mosow-pm, люди, привет
>
> я никак не пойму - можно ли сделать преобразование ключей хэша в массив в 1
> строку с map , например
>
>      my @chunks;
>     for my $chunk ( sort keys %{$ref_chunk} ) {
>         push @chunks, $chunk;
>     }
>
> всю голову себе сломал
> --
> Nikolay Mishin
>
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111010/1326587a/attachment.html>

From angel на domashka.kiev.ua  Mon Oct 10 12:48:41 2011
From: angel на domashka.kiev.ua (Alessandro Gorohovski)
Date: Mon, 10 Oct 2011 22:48:41 +0300
Subject: [Moscow.pm] =?utf-8?b?0LjQtyDRhdGN0YjQsCDQsiDQvNCw0YHRgdC40LI/?=
In-Reply-To: <208111318269384@web70.yandex.ru>
References: <CACEsYN5GcsxGOZLHta=yNHctdCM1=xOcGTrYA7xwe5FagsNaqQ@mail.gmail.com>
	<CANTXRvSv02aB5dy2Tvht1dRYtq5A--8PSy_XZXmaAmAMsknc1g@mail.gmail.com>
	<CAJG5KK6SOruEQGcPW6B=1NZWTxFByaEmqfu6g4a0vF74BRL7qQ@mail.gmail.com>
	<CACEsYN6QJdM3NiRVtSMT_ptZr9xotdM+G8UKL24sst4UR6OkMg@mail.gmail.com>
	<D7127F46-4E30-44F8-9A7D-17B97F8EB213@gmail.com>
	<CABXEPAG+Lb1PJTtKUvTuD_2jPzv+XLZu3EURy45yYd=0NZF1KQ@mail.gmail.com>
	<CAJG5KK5g8MN82JoS7wkDBiH9sEMjWE34kOJ7w9+iD4hg1OG=Vg@mail.gmail.com>
	<CAAPa60g8783vYsrLeK_XB__8XCtu=dOjpPFecSpM5fCP9+DCWg@mail.gmail.com>
	<BC2E1C16-47DF-4F49-A87E-93E7EF006AA6@gmail.com>
	<CAAPa60jf0jWwxPWQCqGcceS7aTEM_s8SG8Ra=y__8Bk5xKTryA@mail.gmail.com>
	<op.v2rqxvy684v92l@proller-nb-w7.ld.yandex.ru>
	<CAAPa60iBWciY7fAJFCS+SEkiOZy4N-8sBZd6Bb+FtCsYie+F9Q@mail.gmail.com>
	<CAJG5KK50-Spd5Mj0XisYutyEyuHNKDygu4QN66EdNX_RAcPM1w@mail.gmail.com>
	<CAAPa60jZ2=yUmzeQd=U1ye=3kPxEbNkDJp8s47uC5rcNONxF5g@mail.gmail.com>
	<CAJG5KK6X9xgO+ZuUXSKr3TkCgDmJXnJWh05vWxpVCq9xkwHhSg@mail.gmail.com>
	<208111318269384@web70.yandex.ru>
Message-ID: <op.v25infd17aizsi@localhost.localdomain>

On Mon, 10 Oct 2011 20:56:24 +0300, Nikolay Mishin wrote:

> Mosow-pm, люди, привет
>
> я никак не пойму - можно ли сделать преобразование ключей хэша в массив  
> в 1 строку

my @chunks = keys $ref_chunk; # for v.14

-- 
С уважением,
АНГ

From evgeniy на kosov.su  Tue Oct 11 00:51:42 2011
From: evgeniy на kosov.su (Evgeniy Kosov)
Date: Tue, 11 Oct 2011 11:51:42 +0400
Subject: [Moscow.pm] =?koi8-r?b?ydogyNzbwSDXIM3B09PJ1z8=?=
In-Reply-To: <208111318269384@web70.yandex.ru>
References: <CACEsYN5GcsxGOZLHta=yNHctdCM1=xOcGTrYA7xwe5FagsNaqQ@mail.gmail.com>	<CAJG5KK6SOruEQGcPW6B=1NZWTxFByaEmqfu6g4a0vF74BRL7qQ@mail.gmail.com>	<CACEsYN6QJdM3NiRVtSMT_ptZr9xotdM+G8UKL24sst4UR6OkMg@mail.gmail.com>	<D7127F46-4E30-44F8-9A7D-17B97F8EB213@gmail.com>	<CABXEPAG+Lb1PJTtKUvTuD_2jPzv+XLZu3EURy45yYd=0NZF1KQ@mail.gmail.com>	<CAJG5KK5g8MN82JoS7wkDBiH9sEMjWE34kOJ7w9+iD4hg1OG=Vg@mail.gmail.com>	<CAAPa60g8783vYsrLeK_XB__8XCtu=dOjpPFecSpM5fCP9+DCWg@mail.gmail.com>	<BC2E1C16-47DF-4F49-A87E-93E7EF006AA6@gmail.com>	<CAAPa60jf0jWwxPWQCqGcceS7aTEM_s8SG8Ra=y__8Bk5xKTryA@mail.gmail.com>	<op.v2rqxvy684v92l@proller-nb-w7.ld.yandex.ru>	<CAAPa60iBWciY7fAJFCS+SEkiOZy4N-8sBZd6Bb+FtCsYie+F9Q@mail.gmail.com>	<CAJG5KK50-Spd5Mj0XisYutyEyuHNKDygu4QN66EdNX_RAcPM1w@mail.gmail.com>	<CAAPa60jZ2=yUmzeQd=U1ye=3kPxEbNkDJp8s47uC5rcNONxF5g@mail.gmail.com>	<CAJG5KK6X9xgO+ZuUXSKr3TkCgDmJXnJWh05vWxpVCq9xkwHhSg@mail.gmail.com>
	<208111318269384@web70.yandex.ru>
Message-ID: <4E93F58E.1050609@kosov.su>

On 10.10.2011 21:56, Nikolay Mishin wrote:
> Mosow-pm, люди, привет
> я никак не пойму - можно ли сделать преобразование ключей хэша в массив
> в 1 строку с map , например
>      my @chunks;
>      for my $chunk ( sort keys %{$ref_chunk} ) {
>          push @chunks, $chunk;
>      }
> всю голову себе сломал

Николай, а можно Вас попросить не заниматься thread hijacking'ом в 
данной рассылке?

Для этого достаточно при отправке нового вопроса с новым топиком жать 
кнопочку Write, а не Reply в соседнем треде.

Спасибо за понимание.

-- 
С уважением,
Евгений Косов

From mi на ya.ru  Tue Oct 11 01:15:37 2011
From: mi на ya.ru (Nikolay Mishin)
Date: Tue, 11 Oct 2011 12:15:37 +0400
Subject: [Moscow.pm] =?koi8-r?b?ydogyNzbwSDXIM3B09PJ1z8=?=
In-Reply-To: <c41f6f99ada71dd9361fbb1818e02c54@aumi.ru>
References: <CACEsYN5GcsxGOZLHta=yNHctdCM1=xOcGTrYA7xwe5FagsNaqQ@mail.gmail.com>
	<CANTXRvSv02aB5dy2Tvht1dRYtq5A--8PSy_XZXmaAmAMsknc1g@mail.gmail.com>
	<CAJG5KK6SOruEQGcPW6B=1NZWTxFByaEmqfu6g4a0vF74BRL7qQ@mail.gmail.com>
	<CACEsYN6QJdM3NiRVtSMT_ptZr9xotdM+G8UKL24sst4UR6OkMg@mail.gmail.com>
	<D7127F46-4E30-44F8-9A7D-17B97F8EB213@gmail.com>
	<CABXEPAG+Lb1PJTtKUvTuD_2jPzv+XLZu3EURy45yYd=0NZF1KQ@mail.gmail.com>
	<CAJG5KK5g8MN82JoS7wkDBiH9sEMjWE34kOJ7w9+iD4hg1OG=Vg@mail.gmail.com>
	<CAAPa60g8783vYsrLeK_XB__8XCtu=dOjpPFecSpM5fCP9+DCWg@mail.gmail.com>
	<BC2E1C16-47DF-4F49-A87E-93E7EF006AA6@gmail.com>
	<CAAPa60jf0jWwxPWQCqGcceS7aTEM_s8SG8Ra=y__8Bk5xKTryA@mail.gmail.com>
	<op.v2rqxvy684v92l@proller-nb-w7.ld.yandex.ru>
	<CAAPa60iBWciY7fAJFCS+SEkiOZy4N-8sBZd6Bb+FtCsYie+F9Q@mail.gmail.com>
	<CAJG5KK50-Spd5Mj0XisYutyEyuHNKDygu4QN66EdNX_RAcPM1w@mail.gmail.com>
	<CAAPa60jZ2=yUmzeQd=U1ye=3kPxEbNkDJp8s47uC5rcNONxF5g@mail.gmail.com>
	<CAJG5KK6X9xgO+ZuUXSKr3TkCgDmJXnJWh05vWxpVCq9xkwHhSg@mail.gmail.com>
	<208111318269384@web70.yandex.ru>
	<c41f6f99ada71dd9361fbb1818e02c54@aumi.ru>
Message-ID: <151111318320937@web14.yandex.ru>

Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111011/895b485d/attachment.html>

From mi на ya.ru  Wed Oct 12 04:40:24 2011
From: mi на ya.ru (Nikolay Mishin)
Date: Wed, 12 Oct 2011 15:40:24 +0400
Subject: [Moscow.pm] =?koi8-r?b?x8XOydLJ0s/Xwc7JxSDSxcfVzNHSzs/HzyDX2dLB?=
	=?koi8-r?b?1sXOydEsIMTB1MEg09TB0tvFINrBxMHOzs/K?=
Message-ID: <107291318419625@web87.yandex.ru>

Hi Moscow-pm,

Я тут сделал генерилку регулярного выражения, например, мне нужно было выводить все файлы старше(включая) 02-Apr-2011

https://gist.github.com/1280987

что скажете?

p.s. по дате файла искать не получиться, т.к. файлы могли сформироваться позднее, имя- это просто метка данных, которые в них лежат
pp.s. ideone не удалось заюзать https://ideone.com/9S0DX т.к. у них нет модулей Regexp::Assemble,Smart::Comments и т.д.
--
Nikolay Mishin

From somerandomlogin на gmail.com  Wed Oct 12 04:52:29 2011
From: somerandomlogin на gmail.com (Jack of Shadows)
Date: Wed, 12 Oct 2011 15:52:29 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?x8XOydLJ0s/Xwc7JxSDSxcfVzNHSzs/HzyDX2dLB?=
	=?koi8-r?b?1sXOydEsIMTB1MEg09TB0tvFINrBxMHOzs/K?=
In-Reply-To: <107291318419625@web87.yandex.ru>
References: <107291318419625@web87.yandex.ru>
Message-ID: <CAH1e3-eh+oH+pgHzyQDbqeU0eRfbH=oYNvkZAbg4J_oRc82p+w@mail.gmail.com>

Хм-м, а как насчёт взять Date::Parse, сконвертить дату в таймстамп?

2011/10/12 Nikolay Mishin <mi на ya.ru>:
> Hi Moscow-pm,
>
> Я тут сделал генерилку регулярного выражения, например, мне нужно было выводить все файлы старше(включая) 02-Apr-2011
>
> https://gist.github.com/1280987
>
> что скажете?
>
> p.s. по дате файла искать не получиться, т.к. файлы могли сформироваться позднее, имя- это просто метка данных, которые в них лежат
> pp.s. ideone не удалось заюзать https://ideone.com/9S0DX т.к. у них нет модулей Regexp::Assemble,Smart::Comments и т.д.
> --
> Nikolay Mishin
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>

From mi на ya.ru  Wed Oct 12 05:23:15 2011
From: mi на ya.ru (Nikolay Mishin)
Date: Wed, 12 Oct 2011 16:23:15 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?x8XOydLJ0s/Xwc7JxSDSxcfVzNHSzs/HzyDX2dLB?=
	=?koi8-r?b?1sXOydEsIMTB1MEg09TB0tvFINrBxMHOzs/K?=
In-Reply-To: <CAH1e3-eh+oH+pgHzyQDbqeU0eRfbH=oYNvkZAbg4J_oRc82p+w@mail.gmail.com>
References: <107291318419625@web87.yandex.ru>
	<CAH1e3-eh+oH+pgHzyQDbqeU0eRfbH=oYNvkZAbg4J_oRc82p+w@mail.gmail.com>
Message-ID: <383001318422195@web59.yandex.ru>

Да, так лучше

https://gist.github.com/1281076

, осталось только понять смогу ли я без root'овых прав использовать этот модуль на SunOS 5.10 

12.10.2011, 15:52, "Jack of Shadows" <somerandomlogin на gmail.com>:
> Хм-м, а как насчёт взять Date::Parse, сконвертить дату в таймстамп?
>
> 2011/10/12 Nikolay Mishin <mi на ya.ru>:
>
>>  Hi Moscow-pm,
>>
>>  Я тут сделал генерилку регулярного выражения, например, мне нужно было выводить все файлы старше(включая) 02-Apr-2011
>>
>>  https://gist.github.com/1280987
>>
>>  что скажете?
>>
>>  p.s. по дате файла искать не получиться, т.к. файлы могли сформироваться позднее, имя- это просто метка данных, которые в них лежат
>>  pp.s. ideone не удалось заюзать https://ideone.com/9S0DX т.к. у них нет модулей Regexp::Assemble,Smart::Comments и т.д.
>>  --
>>  Nikolay Mishin
>>  --
>>  Moscow.pm mailing list
>>  moscow-pm на pm.org | http://moscow.pm.org
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

--
Nikolay Mishin

From mi на ya.ru  Wed Oct 12 05:37:31 2011
From: mi на ya.ru (Nikolay Mishin)
Date: Wed, 12 Oct 2011 16:37:31 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?x8XOydLJ0s/Xwc7JxSDSxcfVzNHSzs/HzyDX2dLB?=
	=?koi8-r?b?1sXOydEsIMTB1MEg09TB0tvFINrBxMHOzs/K?=
In-Reply-To: <383001318422195@web59.yandex.ru>
References: <107291318419625@web87.yandex.ru>
	<CAH1e3-eh+oH+pgHzyQDbqeU0eRfbH=oYNvkZAbg4J_oRc82p+w@mail.gmail.com>
	<383001318422195@web59.yandex.ru>
Message-ID: <415071318423052@web45.yandex.ru>

да, с добавлением 
use lib qw(/home/mishin/perl/utils/TimeDate-1.20/lib);
на солярисе все заработало, спасибо.

12.10.2011, 16:23, "Nikolay Mishin" <mi на ya.ru>:
> Да, так лучше
>
> https://gist.github.com/1281076
>
> , осталось только понять смогу ли я без root'овых прав использовать этот модуль на SunOS 5.10
>
> 12.10.2011, 15:52, "Jack of Shadows" <somerandomlogin на gmail.com>:
>
>>  Хм-м, а как насчёт взять Date::Parse, сконвертить дату в таймстамп?
>>
>>  2011/10/12 Nikolay Mishin <mi на ya.ru>:
>>>   Hi Moscow-pm,
>>>
>>>   Я тут сделал генерилку регулярного выражения, например, мне нужно было выводить все файлы старше(включая) 02-Apr-2011
>>>
>>>   https://gist.github.com/1280987
>>>
>>>   что скажете?
>>>
>>>   p.s. по дате файла искать не получиться, т.к. файлы могли сформироваться позднее, имя- это просто метка данных, которые в них лежат
>>>   pp.s. ideone не удалось заюзать https://ideone.com/9S0DX т.к. у них нет модулей Regexp::Assemble,Smart::Comments и т.д.
>>>   --
>>>   Nikolay Mishin
>>>   --
>>>   Moscow.pm mailing list
>>>   moscow-pm на pm.org | http://moscow.pm.org
>>  --
>>  Moscow.pm mailing list
>>  moscow-pm на pm.org | http://moscow.pm.org
>
> --
> Nikolay Mishin
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

--
Nikolay Mishin

From mi на ya.ru  Wed Oct 12 06:00:30 2011
From: mi на ya.ru (Nikolay Mishin)
Date: Wed, 12 Oct 2011 17:00:30 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?x8XOydLJ0s/Xwc7JxSDSxcfVzNHSzs/HzyDX2dLB?=
	=?koi8-r?b?1sXOydEsIMTB1MEg09TB0tvFINrBxMHOzs/K?=
In-Reply-To: <415071318423052@web45.yandex.ru>
References: <107291318419625@web87.yandex.ru>
	<CAH1e3-eh+oH+pgHzyQDbqeU0eRfbH=oYNvkZAbg4J_oRc82p+w@mail.gmail.com>
	<383001318422195@web59.yandex.ru> <415071318423052@web45.yandex.ru>
Message-ID: <376321318424430@web70.yandex.ru>

но на самом деле регулярное выражение - это параметр другой программы, куда я его хочу передать
и в данном случае тогда нужно исправлять и другую программу (чтобы использовать Date::Parse),
просто вызов программы:

find_files.pl -i input.txt  -r  'qr/.*16-Sep-2011.*[^xg]{1}.zip$/' 

видимо придется вводить еще один параметр --from_date|-fd '02-Apr-2011'
потому что, конечно, генерация регулярного выражения может послужить источником ошиибок, KISS.


12.10.2011, 16:37, "Nikolay Mishin" <mi на ya.ru>:
> да, с добавлением
> use lib qw(/home/mishin/perl/utils/TimeDate-1.20/lib);
> на солярисе все заработало, спасибо.
>
> 12.10.2011, 16:23, "Nikolay Mishin" <mi на ya.ru>:
>
>>  Да, так лучше
>>
>>  https://gist.github.com/1281076
>>
>>  , осталось только понять смогу ли я без root'овых прав использовать этот модуль на SunOS 5.10
>>
>>  12.10.2011, 15:52, "Jack of Shadows" <somerandomlogin на gmail.com>:
>>>   Хм-м, а как насчёт взять Date::Parse, сконвертить дату в таймстамп?
>>>
>>>   2011/10/12 Nikolay Mishin <mi на ya.ru>:
>>>>    Hi Moscow-pm,
>>>>
>>>>    Я тут сделал генерилку регулярного выражения, например, мне нужно было выводить все файлы старше(включая) 02-Apr-2011
>>>>
>>>>    https://gist.github.com/1280987
>>>>
>>>>    что скажете?
>>>>
>>>>    p.s. по дате файла искать не получиться, т.к. файлы могли сформироваться позднее, имя- это просто метка данных, которые в них лежат
>>>>    pp.s. ideone не удалось заюзать https://ideone.com/9S0DX т.к. у них нет модулей Regexp::Assemble,Smart::Comments и т.д.
>>>>    --
>>>>    Nikolay Mishin
>>>>    --
>>>>    Moscow.pm mailing list
>>>>    moscow-pm на pm.org | http://moscow.pm.org
>>>   --
>>>   Moscow.pm mailing list
>>>   moscow-pm на pm.org | http://moscow.pm.org
>>  --
>>  Nikolay Mishin
>>
>>  --
>>  Moscow.pm mailing list
>>  moscow-pm на pm.org | http://moscow.pm.org
>
> --
> Nikolay Mishin
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

--
Nikolay Mishin

From i.petro.77.00 на gmail.com  Fri Oct 14 02:05:23 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 14 Oct 2011 13:05:23 +0400
Subject: [Moscow.pm] =?utf-8?b?TW9qb2xpY2lvdXMg0YLQtdGB0YLQuNGA0L7QstCw?=
 =?utf-8?b?0L3QuNC1IFVzZXJBZ2VudCfQvtCy?=
Message-ID: <20111014090522.GA27274@apache.rbscorp.ru>

Насколько я понимаю Mojo::Test подымает тестовый сервер, делает
запросы к нему.

теперь есть некий проект на Mojo, в каком-то из роутов которого
делаются http-запросы к удаленному серверу (RPC).

Соответственно хотим потестить этот роут:

пишем тест на Mojo::Test который делает post/get-запросы, которые в
свою очередь инициируют запросы на удаленный сервер.

теперь мы хотим чтобы на прохождение тестов удаленный сервер не влиял.
то есть нам надо чтобы запросы на удаленный сервер приходили к нам же
в тест.

Вопрос: как поднять в тесте тестовый Mojo-сервер, к которому сможет
обратиться тестируемый роут да еще так чтобы это все не
заблокировалось?

есть примерчик?

для AE мы обычно используем

AE::HTTP + AE::HTTPD - поскольку там все запросы неблокирующие то им
пофиг что они в одном тесте запущены.

а если роут использует блокирующий Mojo::UserAgent, то как быть? ну
кроме как форкаться

From sharifulin на gmail.com  Fri Oct 14 02:14:12 2011
From: sharifulin на gmail.com (=?KOI8-R?B?4c7B1M/Mycog+8HSycbVzMnO?=)
Date: Fri, 14 Oct 2011 13:14:12 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?TW9qb2xpY2lvdXMg1MXT1MnSz9fBzsnFIFVzZXJB?=
	=?koi8-r?b?Z2VudCfP1w==?=
In-Reply-To: <20111014090522.GA27274@apache.rbscorp.ru>
References: <20111014090522.GA27274@apache.rbscorp.ru>
Message-ID: <CAJG5KK54FtjkfM=gMyNOyLtw6wAWHAVKfb9WpCOfbXDE_aMSxA@mail.gmail.com>

Только Test::Mojo, а Mojo::UserAgent может быть не блокирующим.

В тест окружение можете сделать разные конфиги, тогда запросы будут идти на
ваш тестовый сервер.

Вообще Test::Mojo не поднимает тестовый сервер, а подключает приложение как
модуль и совершает к нему запросы напрямую, либо просто шлёт запросы по
нужному протоколу (HTTP или ws).



2011/10/14 Ivan Petrov <i.petro.77.00 на gmail.com>

> Насколько я понимаю Mojo::Test подымает тестовый сервер, делает
> запросы к нему.
>
> теперь есть некий проект на Mojo, в каком-то из роутов которого
> делаются http-запросы к удаленному серверу (RPC).
>
> Соответственно хотим потестить этот роут:
>
> пишем тест на Mojo::Test который делает post/get-запросы, которые в
> свою очередь инициируют запросы на удаленный сервер.
>
> теперь мы хотим чтобы на прохождение тестов удаленный сервер не влиял.
> то есть нам надо чтобы запросы на удаленный сервер приходили к нам же
> в тест.
>
> Вопрос: как поднять в тесте тестовый Mojo-сервер, к которому сможет
> обратиться тестируемый роут да еще так чтобы это все не
> заблокировалось?
>
> есть примерчик?
>
> для AE мы обычно используем
>
> AE::HTTP + AE::HTTPD - поскольку там все запросы неблокирующие то им
> пофиг что они в одном тесте запущены.
>
> а если роут использует блокирующий Mojo::UserAgent, то как быть? ну
> кроме как форкаться
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
С уважением,
 Анатолий Шарифулин.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111014/af70b4d2/attachment.html>

From ruz на bestpractical.com  Fri Oct 14 06:26:49 2011
From: ruz на bestpractical.com (Ruslan Zakirov)
Date: Fri, 14 Oct 2011 17:26:49 +0400
Subject: [Moscow.pm] =?utf-8?b?TW9qb2xpY2lvdXMg0YLQtdGB0YLQuNGA0L7QstCw?=
	=?utf-8?b?0L3QuNC1IFVzZXJBZ2VudCfQvtCy?=
In-Reply-To: <CAJG5KK54FtjkfM=gMyNOyLtw6wAWHAVKfb9WpCOfbXDE_aMSxA@mail.gmail.com>
References: <20111014090522.GA27274@apache.rbscorp.ru>
	<CAJG5KK54FtjkfM=gMyNOyLtw6wAWHAVKfb9WpCOfbXDE_aMSxA@mail.gmail.com>
Message-ID: <CAMOxC8tRL07iKRDBkW3_=N1xfz+w2HmMFrpYEtbC+0ohV44YEA@mail.gmail.com>

2011/10/14 Анатолий Шарифулин <sharifulin на gmail.com>:
> Только Test::Mojo, а Mojo::UserAgent может быть не блокирующим.
> В тест окружение можете сделать разные конфиги, тогда запросы будут идти на
> ваш тестовый сервер.
> Вообще Test::Mojo не поднимает тестовый сервер, а подключает приложение как
> модуль и совершает к нему запросы напрямую, либо просто шлёт запросы по
> нужному протоколу (HTTP или ws).

Если так, то можно переопределить функцию, которая шлет запросы и
возвращает ответы. Генерить ответы можно прямо в тестах.

> 2011/10/14 Ivan Petrov <i.petro.77.00 на gmail.com>
>>
>> Насколько я понимаю Mojo::Test подымает тестовый сервер, делает
>> запросы к нему.
>>
>> теперь есть некий проект на Mojo, в каком-то из роутов которого
>> делаются http-запросы к удаленному серверу (RPC).
>>
>> Соответственно хотим потестить этот роут:
>>
>> пишем тест на Mojo::Test который делает post/get-запросы, которые в
>> свою очередь инициируют запросы на удаленный сервер.
>>
>> теперь мы хотим чтобы на прохождение тестов удаленный сервер не влиял.
>> то есть нам надо чтобы запросы на удаленный сервер приходили к нам же
>> в тест.
>>
>> Вопрос: как поднять в тесте тестовый Mojo-сервер, к которому сможет
>> обратиться тестируемый роут да еще так чтобы это все не
>> заблокировалось?
>>
>> есть примерчик?
>>
>> для AE мы обычно используем
>>
>> AE::HTTP + AE::HTTPD - поскольку там все запросы неблокирующие то им
>> пофиг что они в одном тесте запущены.
>>
>> а если роут использует блокирующий Mojo::UserAgent, то как быть? ну
>> кроме как форкаться
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>
>
>
> --
> С уважением,
>  Анатолий Шарифулин.
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

-- 
Best regards, Ruslan.

From nordicdyno на yandex.ru  Fri Oct 14 08:10:31 2011
From: nordicdyno на yandex.ru (Orlovsky Alexander)
Date: Fri, 14 Oct 2011 19:10:31 +0400
Subject: [Moscow.pm] =?koi8-r?b?8M/M2NrP18HUxczRzSBEYXRlVGltZQ==?=
Message-ID: <69321318605031@web23.yandex.ru>

Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111014/52ba6c47/attachment.html>

From mi на ya.ru  Fri Oct 14 09:02:33 2011
From: mi на ya.ru (Nikolay Mishin)
Date: Fri, 14 Oct 2011 20:02:33 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?x8XOydLJ0s/Xwc7JxSDSxcfVzNHSzs/HzyDX2dLB?=
	=?koi8-r?b?1sXOydEsIMTB1MEg09TB0tvFINrBxMHOzs/K?=
In-Reply-To: <383001318422195@web59.yandex.ru>
References: <107291318419625@web87.yandex.ru>
	<CAH1e3-eh+oH+pgHzyQDbqeU0eRfbH=oYNvkZAbg4J_oRc82p+w@mail.gmail.com>
	<383001318422195@web59.yandex.ru>
Message-ID: <79721318608153@web33.yandex.ru>

В итоге(рабочий вариант) получилось так

#!/usr/bin/env perl
use strict;
use warnings;

use utf8;
use Carp;
use lib qw(/home/mishin/perl/utils/TimeDate-1.20/lib);
use Date::Parse;
use English qw(-no_match_vars);

our $VERSION = '0.01';

my $start_date = str2time('02-Apr-2011');
my $end_date   = str2time('10-May-2011');

#my $input_time    = str2time($input_date);
my $RGX_DATE_FULL = qr{.*(\d{2}-\w{3}-\d{4}).*}smo;
my @input_data    = <DATA>;

my @res =
  grep { extract_time($_) >= $start_date and extract_time($_) <= $end_date }
  @input_data;

print @res;

sub extract_time {
    my ($search_str) = @_;
    $search_str =~ s/$RGX_DATE_FULL/$1/sm;
    return str2time($search_str);
}

__DATA__
N1089767N_7_SWOPT_03-Jul-2011_78919186.xml
N1089767N_7_SWOPT_25-Jun-2011_72745892.xml
N1089772L_9_SWOPT_03-Jul-2011_78979055.xml
N1089772L_9_SWOPT_01-Apr-2011_78979055.xml
N1089772L_9_SWOPT_02-Apr-2011_78979055.xml
N1089772L_9_SWOPT_22-Apr-2011_78979055.xml
N1089772L_9_SWOPT_30-Apr-2011_78979055.xml
N1089772L_9_SWOPT_20-Jul-2011_69380887.xml
N1089772L_9_SWOPT_29-Jun-2011_74754662.xml
message.110530033311A4259348AS26.A4259348AS_26_SWOPT_01-Jul-2011.xml
message.110530033311A4259348AS26.A4259348AS_26_SWOPT_31-May-2011.xml
A4259348AS_26_SWOPT_29-Jun-2011_74754662.xml
N1089772L_9_SWOPT_03-Feb-2011_78979055.xml
N1089772L_9_SWOPT_01-Mar-2011_78979055.xml
N1089772L_9_SWOPT_02-Jan-2011_78979055.xml
N1089772L_9_SWOPT_22-Feb-2011_78979055.xml


12.10.2011, 16:23, "Nikolay Mishin" <mi на ya.ru>:
> Да, так лучше
>
> https://gist.github.com/1281076
>
> , осталось только понять смогу ли я без root'овых прав использовать этот модуль на SunOS 5.10
>
> 12.10.2011, 15:52, "Jack of Shadows" <somerandomlogin на gmail.com>:
>
>>  Хм-м, а как насчёт взять Date::Parse, сконвертить дату в таймстамп?
>>
>>  2011/10/12 Nikolay Mishin <mi на ya.ru>:
>>>   Hi Moscow-pm,
>>>
>>>   Я тут сделал генерилку регулярного выражения, например, мне нужно было выводить все файлы старше(включая) 02-Apr-2011
>>>
>>>   https://gist.github.com/1280987
>>>
>>>   что скажете?
>>>
>>>   p.s. по дате файла искать не получиться, т.к. файлы могли сформироваться позднее, имя- это просто метка данных, которые в них лежат
>>>   pp.s. ideone не удалось заюзать https://ideone.com/9S0DX т.к. у них нет модулей Regexp::Assemble,Smart::Comments и т.д.
>>>   --
>>>   Nikolay Mishin
>>>   --
>>>   Moscow.pm mailing list
>>>   moscow-pm на pm.org | http://moscow.pm.org
>>  --
>>  Moscow.pm mailing list
>>  moscow-pm на pm.org | http://moscow.pm.org
>
> --
> Nikolay Mishin
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

--
Nikolay Mishin

From evgeniy на kosov.su  Fri Oct 14 09:10:38 2011
From: evgeniy на kosov.su (Evgeniy Kosov)
Date: Fri, 14 Oct 2011 20:10:38 +0400
Subject: [Moscow.pm] =?koi8-r?b?8M/M2NrP18HUxczRzSBEYXRlVGltZQ==?=
In-Reply-To: <69321318605031@web23.yandex.ru>
References: <69321318605031@web23.yandex.ru>
Message-ID: <4E985EFE.6000700@kosov.su>

Александр,

On 14.10.2011 19:10, Orlovsky Alexander wrote:
> Все уже обновили DateTime::TimeZone? (DateTime наверняка многие используют)

Спасибо за напоминание! :)

> проверить:
> 1-й вариант
> perl -MDateTime::TimeZone -e 'print DateTime::TimeZone->VERSION gt
> "1.39" ? "OK\n" : "OLD DT::TZ\n"'
> 2-й вариант
> perl -MDateTime -E 'my $d = DateTime->from_epoch(epoch => 1319929200,
> time_zone => "Europe/Moscow"); say $d->strftime("%F %T") eq "" ? "OK" :
> "up DT::TZ!"'

FYI: 2й вариант не работает.

me на somewhere$ perl -MDateTime -E 'my $d = DateTime->from_epoch(epoch => 
1319929200, time_zone => "Europe/Moscow"); say $d->strftime("%F %T") eq 
"" ? "OK" : "up DT::TZ!"'
up DT::TZ!
me на somewhere$ perl -MDateTime::TimeZone -le 'print 
DateTime::TimeZone->VERSION'
1.40

> системную базу тоже надо обновить:
> http://habrahabr.ru/blogs/sysadm/130363/

-- 
С уважением,
Евгений Косов

From mi на ya.ru  Tue Oct 18 04:34:50 2011
From: mi на ya.ru (Nikolay Mishin)
Date: Tue, 18 Oct 2011 15:34:50 +0400
Subject: [Moscow.pm] proxy and JIRA::Client;
Message-ID: <17381318937690@web78.yandex.ru>

Moscow-pm, коллеги, помогите

пытаюсь приконнектиться к жире

#!/usr/bin/perl

use strict;
use warnings;
use 5.10.0;

use JIRA::Client;
use YAML::Tiny;
my $config = YAML::Tiny::LoadFile( $ENV{PWD} . "/.jirarc_mi" );

my $jira =
  JIRA::Client->new( $config->{url}, $config->{user}, $config->{password} );

500 Can't connect to jira.dot.com:80 (timeout) at c:/strawberry/perl/site/lib/JIRA/Client.pm line 12.

у меня есть прокси (squid) , которым я успешно пользуюсь в питоне:

#!/usr/bin/python

import suds
import urllib2
import atexit

project = "FRWA"
jiraHost = "http://jira.dot:2020/jira/"
jiraUser = "user"
jiraPassword = "passord"
proxy = "localhost:3128"

proxy = urllib2.ProxyHandler({"http": proxy, "https": proxy})
t = suds.transport.http.HttpTransport()
t.urlopener = urllib2.build_opener(proxy)
soap = suds.client.Client(jiraHost + "rpc/soap/jirasoapservice-v2?wsdl", transport=t)
auth = soap.service.login(jiraUser, jiraPassword)
atexit.register(lambda: soap.service.logout())


вопрос, как мне обращаться к жире через прокси proxy = "localhost:3128" ?
как я понимаю здесь идет обращение к веб-сервису через прокси.
спасибо


--
Nikolay Mishin

From somerandomlogin на gmail.com  Tue Oct 18 04:46:26 2011
From: somerandomlogin на gmail.com (Jack of Shadows)
Date: Tue, 18 Oct 2011 15:46:26 +0400
Subject: [Moscow.pm] proxy and JIRA::Client;
In-Reply-To: <17381318937690@web78.yandex.ru>
References: <17381318937690@web78.yandex.ru>
Message-ID: <CAH1e3-dKTWt2eLP0JNHGzeLNOE2E+W+PtHqkcLsm1eaBXps-5w@mail.gmail.com>

1. Чисто теоретический подход:
Хм-м, ну, глядя на исходники JIRA::Client:

sub new {
    my ($class, $base_url, $user, $pass, @args) = @_;

    my $soap = SOAP::Lite->proxy("$base_url/rpc/soap/jirasoapservice-v2?wsdl",
@args);

...
}

...и на документацию SOAP::Lite:
$client->proxy('http://soap.xml.info/ endPoint');

Можно попробовать сказать в конструкторе:
JIRA::Client->new( 'http://localhost:3128 ' . $config->{url},
$config->{user}, $config->{password} );

(Хотя выглядит это всё несколько сомнительно и на практике мной не
проверялось 8) )

2. А вообще наверное нужно пойти почитать, первый результат в гугле:
http://cookbook.soaplite.com/#specifying%20proxy


2011/10/18 Nikolay Mishin <mi на ya.ru>:
> Moscow-pm, коллеги, помогите
>
> пытаюсь приконнектиться к жире
>
> #!/usr/bin/perl
>
> use strict;
> use warnings;
> use 5.10.0;
>
> use JIRA::Client;
> use YAML::Tiny;
> my $config = YAML::Tiny::LoadFile( $ENV{PWD} . "/.jirarc_mi" );
>
> my $jira =
>  JIRA::Client->new( $config->{url}, $config->{user}, $config->{password} );
>
> 500 Can't connect to jira.dot.com:80 (timeout) at c:/strawberry/perl/site/lib/JIRA/Client.pm line 12.
>
> у меня есть прокси (squid) , которым я успешно пользуюсь в питоне:
>
> #!/usr/bin/python
>
> import suds
> import urllib2
> import atexit
>
> project = "FRWA"
> jiraHost = "http://jira.dot:2020/jira/"
> jiraUser = "user"
> jiraPassword = "passord"
> proxy = "localhost:3128"
>
> proxy = urllib2.ProxyHandler({"http": proxy, "https": proxy})
> t = suds.transport.http.HttpTransport()
> t.urlopener = urllib2.build_opener(proxy)
> soap = suds.client.Client(jiraHost + "rpc/soap/jirasoapservice-v2?wsdl", transport=t)
> auth = soap.service.login(jiraUser, jiraPassword)
> atexit.register(lambda: soap.service.logout())
>
>
> вопрос, как мне обращаться к жире через прокси proxy = "localhost:3128" ?
> как я понимаю здесь идет обращение к веб-сервису через прокси.
> спасибо
>
>
> --
> Nikolay Mishin
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>

From isage на aumi.ru  Tue Oct 18 04:50:09 2011
From: isage на aumi.ru (iSage)
Date: Tue, 18 Oct 2011 14:50:09 +0300
Subject: [Moscow.pm] proxy and JIRA::Client;
In-Reply-To: <CAH1e3-dKTWt2eLP0JNHGzeLNOE2E+W+PtHqkcLsm1eaBXps-5w@mail.gmail.com>
References: <17381318937690@web78.yandex.ru>
	<CAH1e3-dKTWt2eLP0JNHGzeLNOE2E+W+PtHqkcLsm1eaBXps-5w@mail.gmail.com>
Message-ID: <714349730f2714a525191bd2d8eef629@aumi.ru>

Смотрю в книгу - вижу фигу, гхм.

JIRA::Client->new( $config->{url}, $config->{user},
$config->{password}, proxy => ["http" => "http://my.proxy.server"] );


On Tue, 18 Oct 2011 15:46:26 +0400, Jack of Shadows
<somerandomlogin на gmail.com> wrote:
> 1. Чисто теоретический подход:
> Хм-м, ну, глядя на исходники JIRA::Client:
> 
> sub new {
>     my ($class, $base_url, $user, $pass, @args) = @_;
> 
>     my $soap =
> SOAP::Lite->proxy("$base_url/rpc/soap/jirasoapservice-v2?wsdl",
> @args);
> 
> ...
> }
> 
> ...и на документацию SOAP::Lite:
> $client->proxy('http://soap.xml.info/ endPoint');
> 
> Можно попробовать сказать в конструкторе:
> JIRA::Client->new( 'http://localhost:3128 ' . $config->{url},
> $config->{user}, $config->{password} );
> 
> (Хотя выглядит это всё несколько сомнительно и на практике мной не
> проверялось 8) )
> 
> 2. А вообще наверное нужно пойти почитать, первый результат в гугле:
> http://cookbook.soaplite.com/#specifying%20proxy
> 
> 
> 2011/10/18 Nikolay Mishin <mi на ya.ru>:
>> Moscow-pm, коллеги, помогите
>>
>> пытаюсь приконнектиться к жире
>>
>> #!/usr/bin/perl
>>
>> use strict;
>> use warnings;
>> use 5.10.0;
>>
>> use JIRA::Client;
>> use YAML::Tiny;
>> my $config = YAML::Tiny::LoadFile( $ENV{PWD} . "/.jirarc_mi" );
>>
>> my $jira =
>>  JIRA::Client->new( $config->{url}, $config->{user}, $config->{password} );
>>
>> 500 Can't connect to jira.dot.com:80 (timeout) at c:/strawberry/perl/site/lib/JIRA/Client.pm line 12.
>>
>> у меня есть прокси (squid) , которым я успешно пользуюсь в питоне:
>>
>> #!/usr/bin/python
>>
>> import suds
>> import urllib2
>> import atexit
>>
>> project = "FRWA"
>> jiraHost = "http://jira.dot:2020/jira/"
>> jiraUser = "user"
>> jiraPassword = "passord"
>> proxy = "localhost:3128"
>>
>> proxy = urllib2.ProxyHandler({"http": proxy, "https": proxy})
>> t = suds.transport.http.HttpTransport()
>> t.urlopener = urllib2.build_opener(proxy)
>> soap = suds.client.Client(jiraHost + "rpc/soap/jirasoapservice-v2?wsdl", transport=t)
>> auth = soap.service.login(jiraUser, jiraPassword)
>> atexit.register(lambda: soap.service.logout())
>>
>>
>> вопрос, как мне обращаться к жире через прокси proxy = "localhost:3128" ?
>> как я понимаю здесь идет обращение к веб-сервису через прокси.
>> спасибо
>>
>>
>> --
>> Nikolay Mishin
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>


From isage на aumi.ru  Tue Oct 18 04:52:43 2011
From: isage на aumi.ru (iSage)
Date: Tue, 18 Oct 2011 14:52:43 +0300
Subject: [Moscow.pm] proxy and JIRA::Client;
In-Reply-To: <714349730f2714a525191bd2d8eef629@aumi.ru>
References: <17381318937690@web78.yandex.ru>
	<CAH1e3-dKTWt2eLP0JNHGzeLNOE2E+W+PtHqkcLsm1eaBXps-5w@mail.gmail.com>
	<714349730f2714a525191bd2d8eef629@aumi.ru>
Message-ID: <9a51f5e9845717b7f1ef5ed393248cd0@aumi.ru>

http://search.cpan.org/~mkutter/SOAP-Lite-0.714/lib/SOAP/Transport.pod#HTTP_PROXY_SETTINGS
В догонку.

On Tue, 18 Oct 2011 14:50:09 +0300, iSage <isage на aumi.ru> wrote:
> Смотрю в книгу - вижу фигу, гхм.
> 
> JIRA::Client->new( $config->{url}, $config->{user},
> $config->{password}, proxy => ["http" => "http://my.proxy.server"] );
> 
> 
> On Tue, 18 Oct 2011 15:46:26 +0400, Jack of Shadows
> <somerandomlogin на gmail.com> wrote:
>> 1. Чисто теоретический подход:
>> Хм-м, ну, глядя на исходники JIRA::Client:
>>
>> sub new {
>>     my ($class, $base_url, $user, $pass, @args) = @_;
>>
>>     my $soap =
>> SOAP::Lite->proxy("$base_url/rpc/soap/jirasoapservice-v2?wsdl",
>> @args);
>>
>> ...
>> }
>>
>> ...и на документацию SOAP::Lite:
>> $client->proxy('http://soap.xml.info/ endPoint');
>>
>> Можно попробовать сказать в конструкторе:
>> JIRA::Client->new( 'http://localhost:3128 ' . $config->{url},
>> $config->{user}, $config->{password} );
>>
>> (Хотя выглядит это всё несколько сомнительно и на практике мной не
>> проверялось 8) )
>>
>> 2. А вообще наверное нужно пойти почитать, первый результат в гугле:
>> http://cookbook.soaplite.com/#specifying%20proxy
>>
>>
>> 2011/10/18 Nikolay Mishin <mi на ya.ru>:
>>> Moscow-pm, коллеги, помогите
>>>
>>> пытаюсь приконнектиться к жире
>>>
>>> #!/usr/bin/perl
>>>
>>> use strict;
>>> use warnings;
>>> use 5.10.0;
>>>
>>> use JIRA::Client;
>>> use YAML::Tiny;
>>> my $config = YAML::Tiny::LoadFile( $ENV{PWD} . "/.jirarc_mi" );
>>>
>>> my $jira =
>>>  JIRA::Client->new( $config->{url}, $config->{user}, $config->{password} );
>>>
>>> 500 Can't connect to jira.dot.com:80 (timeout) at c:/strawberry/perl/site/lib/JIRA/Client.pm line 12.
>>>
>>> у меня есть прокси (squid) , которым я успешно пользуюсь в питоне:
>>>
>>> #!/usr/bin/python
>>>
>>> import suds
>>> import urllib2
>>> import atexit
>>>
>>> project = "FRWA"
>>> jiraHost = "http://jira.dot:2020/jira/"
>>> jiraUser = "user"
>>> jiraPassword = "passord"
>>> proxy = "localhost:3128"
>>>
>>> proxy = urllib2.ProxyHandler({"http": proxy, "https": proxy})
>>> t = suds.transport.http.HttpTransport()
>>> t.urlopener = urllib2.build_opener(proxy)
>>> soap = suds.client.Client(jiraHost + "rpc/soap/jirasoapservice-v2?wsdl", transport=t)
>>> auth = soap.service.login(jiraUser, jiraPassword)
>>> atexit.register(lambda: soap.service.logout())
>>>
>>>
>>> вопрос, как мне обращаться к жире через прокси proxy = "localhost:3128" ?
>>> как я понимаю здесь идет обращение к веб-сервису через прокси.
>>> спасибо
>>>
>>>
>>> --
>>> Nikolay Mishin
>>> --
>>> Moscow.pm mailing list
>>> moscow-pm на pm.org | http://moscow.pm.org
>>>


From somerandomlogin на gmail.com  Tue Oct 18 04:52:59 2011
From: somerandomlogin на gmail.com (Jack of Shadows)
Date: Tue, 18 Oct 2011 15:52:59 +0400
Subject: [Moscow.pm] proxy and JIRA::Client;
In-Reply-To: <714349730f2714a525191bd2d8eef629@aumi.ru>
References: <17381318937690@web78.yandex.ru>
	<CAH1e3-dKTWt2eLP0JNHGzeLNOE2E+W+PtHqkcLsm1eaBXps-5w@mail.gmail.com>
	<714349730f2714a525191bd2d8eef629@aumi.ru>
Message-ID: <CAH1e3-eoF0LEg=SzQ9XnU5fc6b3vxTORh0B8DDx07ddovhPywQ@mail.gmail.com>

Да, действительно :-D
Ну для начала надо было хотя бы книгу увидеть. 8)

2011/10/18 iSage <isage на aumi.ru>:
> Смотрю в книгу - вижу фигу, гхм.
>
> JIRA::Client->new( $config->{url}, $config->{user},
> $config->{password}, proxy => ["http" => "http://my.proxy.server"] );
>
>
> On Tue, 18 Oct 2011 15:46:26 +0400, Jack of Shadows
> <somerandomlogin на gmail.com> wrote:
>> 1. Чисто теоретический подход:
>> Хм-м, ну, глядя на исходники JIRA::Client:
>>
>> sub new {
>>     my ($class, $base_url, $user, $pass, @args) = @_;
>>
>>     my $soap =
>> SOAP::Lite->proxy("$base_url/rpc/soap/jirasoapservice-v2?wsdl",
>> @args);
>>
>> ...
>> }
>>
>> ...и на документацию SOAP::Lite:
>> $client->proxy('http://soap.xml.info/ endPoint');
>>
>> Можно попробовать сказать в конструкторе:
>> JIRA::Client->new( 'http://localhost:3128 ' . $config->{url},
>> $config->{user}, $config->{password} );
>>
>> (Хотя выглядит это всё несколько сомнительно и на практике мной не
>> проверялось 8) )
>>
>> 2. А вообще наверное нужно пойти почитать, первый результат в гугле:
>> http://cookbook.soaplite.com/#specifying%20proxy
>>
>>
>> 2011/10/18 Nikolay Mishin <mi на ya.ru>:
>>> Moscow-pm, коллеги, помогите
>>>
>>> пытаюсь приконнектиться к жире
>>>
>>> #!/usr/bin/perl
>>>
>>> use strict;
>>> use warnings;
>>> use 5.10.0;
>>>
>>> use JIRA::Client;
>>> use YAML::Tiny;
>>> my $config = YAML::Tiny::LoadFile( $ENV{PWD} . "/.jirarc_mi" );
>>>
>>> my $jira =
>>>  JIRA::Client->new( $config->{url}, $config->{user}, $config->{password} );
>>>
>>> 500 Can't connect to jira.dot.com:80 (timeout) at c:/strawberry/perl/site/lib/JIRA/Client.pm line 12.
>>>
>>> у меня есть прокси (squid) , которым я успешно пользуюсь в питоне:
>>>
>>> #!/usr/bin/python
>>>
>>> import suds
>>> import urllib2
>>> import atexit
>>>
>>> project = "FRWA"
>>> jiraHost = "http://jira.dot:2020/jira/"
>>> jiraUser = "user"
>>> jiraPassword = "passord"
>>> proxy = "localhost:3128"
>>>
>>> proxy = urllib2.ProxyHandler({"http": proxy, "https": proxy})
>>> t = suds.transport.http.HttpTransport()
>>> t.urlopener = urllib2.build_opener(proxy)
>>> soap = suds.client.Client(jiraHost + "rpc/soap/jirasoapservice-v2?wsdl", transport=t)
>>> auth = soap.service.login(jiraUser, jiraPassword)
>>> atexit.register(lambda: soap.service.logout())
>>>
>>>
>>> вопрос, как мне обращаться к жире через прокси proxy = "localhost:3128" ?
>>> как я понимаю здесь идет обращение к веб-сервису через прокси.
>>> спасибо
>>>
>>>
>>> --
>>> Nikolay Mishin
>>> --
>>> Moscow.pm mailing list
>>> moscow-pm на pm.org | http://moscow.pm.org
>>>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>

From mi на ya.ru  Tue Oct 18 06:00:53 2011
From: mi на ya.ru (Nikolay Mishin)
Date: Tue, 18 Oct 2011 17:00:53 +0400
Subject: [Moscow.pm] proxy and JIRA::Client;
In-Reply-To: <714349730f2714a525191bd2d8eef629@aumi.ru>
References: <17381318937690@web78.yandex.ru>
	<CAH1e3-dKTWt2eLP0JNHGzeLNOE2E+W+PtHqkcLsm1eaBXps-5w@mail.gmail.com>
	<714349730f2714a525191bd2d8eef629@aumi.ru>
Message-ID: <90661318942853@web60.yandex.ru>

Да, круто, спасибо,

use JIRA::Client;
use YAML::Tiny;
my $config = YAML::Tiny::LoadFile( $ENV{PWD} . "/.jirarc_mi" );

my $jira =
  JIRA::Client->new( $config->{url}, $config->{user}, $config->{password},
    proxy => [ "http" => $config->{proxy} ] );

так, вроде работает squid правда глюит под win7 думаю cntlm поставить что ли..

спасибо за примеры, действительно не видел очевидных вещей.


18.10.2011, 15:50, "iSage" <isage на aumi.ru>:
> Смотрю в книгу - вижу фигу, гхм.
>
> JIRA::Client->new( $config->{url}, $config->{user},
> $config->{password}, proxy => ["http" => "http://my.proxy.server"] );
>
> On Tue, 18 Oct 2011 15:46:26 +0400, Jack of Shadows
> <somerandomlogin на gmail.com> wrote:
>
>>  1. Чисто теоретический подход:
>>  Хм-м, ну, глядя на исходники JIRA::Client:
>>
>>  sub new {
>>      my ($class, $base_url, $user, $pass, @args) = @_;
>>
>>      my $soap =
>>  SOAP::Lite->proxy("$base_url/rpc/soap/jirasoapservice-v2?wsdl",
>>  @args);
>>
>>  ...
>>  }
>>
>>  ...и на документацию SOAP::Lite:
>>  $client->proxy('http://soap.xml.info/ endPoint');
>>
>>  Можно попробовать сказать в конструкторе:
>>  JIRA::Client->new( 'http://localhost:3128 ' . $config->{url},
>>  $config->{user}, $config->{password} );
>>
>>  (Хотя выглядит это всё несколько сомнительно и на практике мной не
>>  проверялось 8) )
>>
>>  2. А вообще наверное нужно пойти почитать, первый результат в гугле:
>>  http://cookbook.soaplite.com/#specifying%20proxy
>>
>>  2011/10/18 Nikolay Mishin <mi на ya.ru>:
>>>  Moscow-pm, коллеги, помогите
>>>
>>>  пытаюсь приконнектиться к жире
>>>
>>>  #!/usr/bin/perl
>>>
>>>  use strict;
>>>  use warnings;
>>>  use 5.10.0;
>>>
>>>  use JIRA::Client;
>>>  use YAML::Tiny;
>>>  my $config = YAML::Tiny::LoadFile( $ENV{PWD} . "/.jirarc_mi" );
>>>
>>>  my $jira =
>>>   JIRA::Client->new( $config->{url}, $config->{user}, $config->{password} );
>>>
>>>  500 Can't connect to jira.dot.com:80 (timeout) at c:/strawberry/perl/site/lib/JIRA/Client.pm line 12.
>>>
>>>  у меня есть прокси (squid) , которым я успешно пользуюсь в питоне:
>>>
>>>  #!/usr/bin/python
>>>
>>>  import suds
>>>  import urllib2
>>>  import atexit
>>>
>>>  project = "FRWA"
>>>  jiraHost = "http://jira.dot:2020/jira/"
>>>  jiraUser = "user"
>>>  jiraPassword = "passord"
>>>  proxy = "localhost:3128"
>>>
>>>  proxy = urllib2.ProxyHandler({"http": proxy, "https": proxy})
>>>  t = suds.transport.http.HttpTransport()
>>>  t.urlopener = urllib2.build_opener(proxy)
>>>  soap = suds.client.Client(jiraHost + "rpc/soap/jirasoapservice-v2?wsdl", transport=t)
>>>  auth = soap.service.login(jiraUser, jiraPassword)
>>>  atexit.register(lambda: soap.service.logout())
>>>
>>>  вопрос, как мне обращаться к жире через прокси proxy = "localhost:3128" ?
>>>  как я понимаю здесь идет обращение к веб-сервису через прокси.
>>>  спасибо
>>>
>>>  --
>>>  Nikolay Mishin
>>>  --
>>>  Moscow.pm mailing list
>>>  moscow-pm на pm.org | http://moscow.pm.org
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

--
Nikolay Mishin

From chesnokov.ilya на gmail.com  Wed Oct 19 03:24:19 2011
From: chesnokov.ilya на gmail.com (Ilya Chesnokov)
Date: Wed, 19 Oct 2011 14:24:19 +0400
Subject: [Moscow.pm] =?utf-8?b?TWl5YWdhd2Eg0L4g0LLQuNC00LXQviDRgSBZQVBD?=
Message-ID: <CANh0x-w=9iCzgTcx63G6ihVFcm9D4Lh_fkjv01qN4-7Cfhdb7g@mail.gmail.com>

https://twitter.com/#!/miyagawa/status/126593159143751680

-- 
Ilya Chesnokov

From timonnius на gmail.com  Wed Oct 19 04:50:06 2011
From: timonnius на gmail.com (=?KOI8-R?B?9MnNz8bFyiDtwdLLz9c=?=)
Date: Wed, 19 Oct 2011 15:50:06 +0400
Subject: [Moscow.pm] =?koi8-r?b?8NLP18XSy8Eg08/T1M/RzsnRINPF1Mk=?=
Message-ID: <CA+7T7RdMPX8_-Mb2EX5+K_Twt9WH7h+u8wQcTwphidTf-kkwSA@mail.gmail.com>

Доброго времени суток. Подскажите,  встроенные средства (или модули cpan)
для проверки скорости интернет соединения. Поиск в гугле и библиотеке CPAN
ничего дельного не дал. Если таковых средств нет, буду благодарен за идею
как можно это сделать.
(мне нужно определить скорость канала между четырьмя моими VPS серверами).
Заранее благодарен всем за ответ. С уважением Тимофей.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111019/df780b80/attachment.html>

From ivan на bessarabov.ru  Wed Oct 19 04:52:51 2011
From: ivan на bessarabov.ru (=?UTF-8?B?0JjQstCw0L0g0JHQtdGB0YHQsNGA0LDQsdC+0LI=?=)
Date: Wed, 19 Oct 2011 15:52:51 +0400
Subject: [Moscow.pm] =?utf-8?b?0J/RgNC+0LLQtdGA0LrQsCDRgdC+0YHRgtC+0Y8=?=
	=?utf-8?b?0L3QuNGPINGB0LXRgtC4?=
In-Reply-To: <CA+7T7RdMPX8_-Mb2EX5+K_Twt9WH7h+u8wQcTwphidTf-kkwSA@mail.gmail.com>
References: <CA+7T7RdMPX8_-Mb2EX5+K_Twt9WH7h+u8wQcTwphidTf-kkwSA@mail.gmail.com>
Message-ID: <CACEsYN5MTna0zpo=jE+5Yqb60jbtbz4-q+r_mJOTpWr__hXzkA@mail.gmail.com>

http://stackoverflow.com/questions/2707858/is-there-a-perl-module-to-test-internet-connection-speed

19 октября 2011 г. 15:50 пользователь Тимофей Марков
<timonnius на gmail.com> написал:
> Доброго времени суток. Подскажите,  встроенные средства (или модули cpan)
> для проверки скорости интернет соединения. Поиск в гугле и библиотеке CPAN
> ничего дельного не дал. Если таковых средств нет, буду благодарен за идею
> как можно это сделать.
> (мне нужно определить скорость канала между четырьмя моими VPS серверами).
> Заранее благодарен всем за ответ. С уважением Тимофей.
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>

From worldmind на mail.ru  Wed Oct 19 05:42:56 2011
From: worldmind на mail.ru (Alexey Shrub)
Date: Wed, 19 Oct 2011 16:42:56 +0400
Subject: [Moscow.pm] =?koi8-r?b?8NLP18XSy8Eg08/T1M/RzsnRINPF1Mk=?=
In-Reply-To: <CA+7T7RdMPX8_-Mb2EX5+K_Twt9WH7h+u8wQcTwphidTf-kkwSA@mail.gmail.com>
References: <CA+7T7RdMPX8_-Mb2EX5+K_Twt9WH7h+u8wQcTwphidTf-kkwSA@mail.gmail.com>
Message-ID: <1319028176.3531.12.camel@host>

Может пригодится
http://iperf.sourceforge.net/

On Ср., 2011-10-19 at 15:50 +0400, Тимофей Марков wrote:
> Доброго времени суток. Подскажите,  встроенные средства (или модули
> cpan) для проверки скорости интернет соединения. Поиск в гугле и
> библиотеке CPAN ничего дельного не дал. Если таковых средств нет, буду
> благодарен за идею как можно это сделать.
> (мне нужно определить скорость канала между четырьмя моими VPS
> серверами).
> Заранее благодарен всем за ответ. С уважением Тимофей.



From shafiev на gmail.com  Wed Oct 19 05:44:14 2011
From: shafiev на gmail.com (Naim Shafiev)
Date: Wed, 19 Oct 2011 17:44:14 +0500
Subject: [Moscow.pm] =?koi8-r?b?8NLP18XSy8Eg08/T1M/RzsnRINPF1Mk=?=
In-Reply-To: <1319028176.3531.12.camel@host>
References: <CA+7T7RdMPX8_-Mb2EX5+K_Twt9WH7h+u8wQcTwphidTf-kkwSA@mail.gmail.com>
	<1319028176.3531.12.camel@host>
Message-ID: <CAGYhLe04a6xwuneFbDSdfLHs=3MLzSkJCcnbqAvJgLN7H-AO_w@mail.gmail.com>

Или же просто по netflow/sflow скорость каптить - те же модули со
спана или мой любимый nfsen   ,  у вас же они через свитч или раутер
подрублены между собой  скорее всего

19 октября 2011 г. 17:42 пользователь Alexey Shrub <worldmind на mail.ru> написал:
> Может пригодится
> http://iperf.sourceforge.net/
>
> On Ср., 2011-10-19 at 15:50 +0400, Тимофей Марков wrote:
>> Доброго времени суток. Подскажите,  встроенные средства (или модули
>> cpan) для проверки скорости интернет соединения. Поиск в гугле и
>> библиотеке CPAN ничего дельного не дал. Если таковых средств нет, буду
>> благодарен за идею как можно это сделать.
>> (мне нужно определить скорость канала между четырьмя моими VPS
>> серверами).
>> Заранее благодарен всем за ответ. С уважением Тимофей.
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>

From mi на ya.ru  Wed Oct 19 11:53:10 2011
From: mi на ya.ru (Nikolay Mishin)
Date: Wed, 19 Oct 2011 22:53:10 +0400
Subject: [Moscow.pm] Module::Starter::PBP
Message-ID: <414481319050390@web3.yandex.ru>

Hi Moscow-pm
Замечательный модуль Module::Starter::PBP https://metacpan.org/module/Module::Starter::PBP

все мне сгенерил как нужно, после
perl -MModule::Starter::PBP=setup
правда пришлось прописывать HOME в system environment variables,
чтобы было куда ему .module-starter\config  прописывать

, но, предлагаемые Домианом Конвеем модули 

use Perl6::Export;
use Perl6::Slurp;
use version;
my $VERSION = qv('0.0.1');
не работают под Win7
https://gist.github.com/1299248

хотя Perl6::Export очень даже симпатичный, приходиться использовать старые добрые 

our ( @ISA, $VERSION, @EXPORT_OK );

BEGIN {
    $VERSION = '0.0.1';

    require Exporter;
    @ISA       = qw(Exporter);
    @EXPORT_OK = qw(get_user_param);

}    


видимо win находиться у perl в загоне?

Спасибо.

--
Nikolay Mishin

From ykorshak на gmail.com  Wed Oct 19 12:12:04 2011
From: ykorshak на gmail.com (Yaroslav Korshak)
Date: Wed, 19 Oct 2011 22:12:04 +0300
Subject: [Moscow.pm] Module::Starter::PBP
In-Reply-To: <414481319050390@web3.yandex.ru>
References: <414481319050390@web3.yandex.ru>
Message-ID: <4E9F2104.20303@gmail.com>

Привет Николай, привет Moscow.pm

Последние релизы Perl6::Export и Perl6::Slurp - 2004 год. Боюсь, о Win7 
тогда еще не знали, а багрепортов на эти модули никто не открывал. 
Вероятно, Демиан просто не знает о существовании проблемы как таковой.

Хочу также заметить...
В Module::Starter::PBP есть ряд неприятных огрехов, на которые есть 
тикеты еще с 2005 года и которые так и не были исправлены. Очевидно, что 
у автора нету времени. Поэтому я позволил себе создать github 
репозиторий и исправить в нем наиболее неприятные ошибки: 
https://github.com/yko/module-starter-pbp
Для начала - те которые касаются тестов (которые будут умирать, если в 
системе не установлен Test::Perl::Critic) и версий в шаблонах.

Замечу, что тикет о проблеме "Breaks on standard windows home 
directories" <https://rt.cpan.org/Public/Bug/Display.html?id=21557>, с 
которой Вы скорее всего имеете дело (HOME),  был открыт в 2006 году: 
https://rt.cpan.org/Public/Bug/Display.html?id=21557.

Возможно, Вы заинтересованы в том, чтобы исправить эту ошибку и написать 
соответствующие тесты.
Я собираюсь в скорем времени просить у автора применить мои патчи скопом 
или доверить мне права на дальнейшее сопровождение модуля и изменения 
просто войдут в следующую версию модуля.

Что скажете?

--
Regards
yko

On 10/19/2011 09:53 PM, Nikolay Mishin wrote:
> Hi Moscow-pm
> Замечательный модуль Module::Starter::PBP https://metacpan.org/module/Module::Starter::PBP
>
> все мне сгенерил как нужно, после
> perl -MModule::Starter::PBP=setup
> правда пришлось прописывать HOME в system environment variables,
> чтобы было куда ему .module-starter\config  прописывать
>
> , но, предлагаемые Домианом Конвеем модули
>
> use Perl6::Export;
> use Perl6::Slurp;
> use version;
> my $VERSION = qv('0.0.1');
> не работают под Win7
> https://gist.github.com/1299248

From meettya на gmail.com  Wed Oct 19 13:44:49 2011
From: meettya на gmail.com (Dmitry Karpich)
Date: Thu, 20 Oct 2011 00:44:49 +0400
Subject: [Moscow.pm] Module::Starter::PBP
In-Reply-To: <414481319050390@web3.yandex.ru>
References: <414481319050390@web3.yandex.ru>
Message-ID: <75647DB0-FBEB-4261-AA5D-85910D7E4908@gmail.com>


On Oct 19, 2011, at 10:53 PM, Nikolay Mishin wrote:

> Hi Moscow-pm
> Замечательный модуль Module::Starter::PBP https://metacpan.org/module/Module::Starter::PBP
> 

Ну не знаю, ванильный Module::Starter вполне устраивает.

> все мне сгенерил как нужно, после
> perl -MModule::Starter::PBP=setup
> правда пришлось прописывать HOME в system environment variables,
> чтобы было куда ему .module-starter\config  прописывать
> 
> , но, предлагаемые Домианом Конвеем модули 
> 
> use Perl6::Export;
> use Perl6::Slurp;
> 

Крайне рекомендую посмотреть на File::Map, он для работы с файлами ИДЕОЛОГИЧЕСКИ лучше. ИМХО. Особенно если только чтение и интересует.

> 
> 
> видимо win находиться у perl в загоне?
> 
> Спасибо.
> 
> --
> Nikolay Mishin
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111020/f2cd5da2/attachment.html>

From mi на ya.ru  Wed Oct 19 21:30:50 2011
From: mi на ya.ru (Nikolay Mishin)
Date: Thu, 20 Oct 2011 08:30:50 +0400
Subject: [Moscow.pm] Module::Starter::PBP
In-Reply-To: <4E9F2104.20303@gmail.com>
References: <414481319050390@web3.yandex.ru> <4E9F2104.20303@gmail.com>
Message-ID: <271181319085050@web75.yandex.ru>

Спасибо Ярослав, нужное дело
1.
кстати home добавить можно reg файлом,например, таким home.reg:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment]
"HOME"="%USERPROFILE%"

2. да, я напишу тест про HOME и запушу тебе в репозиторий
и да, заинтересован в улучшении(исправлении) этого модуля, хотя
при запуске perl -MModule::Starter::PBP=setup
он и спрашивает, где ваша HOME директория, однако, при запуске
module-starter --module=Your::New::Module
module-starter уже  не видит HOME (т.к. переменная не установлена)
и ругается
3. ну и Домиан, конечно, расширяет сознание, чего стоят его конструкции типа:
  my %contents_of = do { local $/; "", split /_____\[ (\S+) \]_+\n/, <DATA> };
!!! нереально


19.10.2011, 23:12, "Yaroslav Korshak" <ykorshak на gmail.com>:
> Привет Николай, привет Moscow.pm
>
> Последние релизы Perl6::Export и Perl6::Slurp - 2004 год. Боюсь, о Win7
> тогда еще не знали, а багрепортов на эти модули никто не открывал.
> Вероятно, Демиан просто не знает о существовании проблемы как таковой.
>
> Хочу также заметить...
> В Module::Starter::PBP есть ряд неприятных огрехов, на которые есть
> тикеты еще с 2005 года и которые так и не были исправлены. Очевидно, что
> у автора нету времени. Поэтому я позволил себе создать github
> репозиторий и исправить в нем наиболее неприятные ошибки:
> https://github.com/yko/module-starter-pbp
> Для начала - те которые касаются тестов (которые будут умирать, если в
> системе не установлен Test::Perl::Critic) и версий в шаблонах.
>
> Замечу, что тикет о проблеме "Breaks on standard windows home
> directories" <https://rt.cpan.org/Public/Bug/Display.html?id=21557>, с
> которой Вы скорее всего имеете дело (HOME),  был открыт в 2006 году:
> https://rt.cpan.org/Public/Bug/Display.html?id=21557.
>
> Возможно, Вы заинтересованы в том, чтобы исправить эту ошибку и написать
> соответствующие тесты.
> Я собираюсь в скорем времени просить у автора применить мои патчи скопом
> или доверить мне права на дальнейшее сопровождение модуля и изменения
> просто войдут в следующую версию модуля.
>
> Что скажете?
>
> --
> Regards
> yko
>
> On 10/19/2011 09:53 PM, Nikolay Mishin wrote:
>
>>  Hi Moscow-pm
>>  Замечательный модуль Module::Starter::PBP https://metacpan.org/module/Module::Starter::PBP
>>
>>  все мне сгенерил как нужно, после
>>  perl -MModule::Starter::PBP=setup
>>  правда пришлось прописывать HOME в system environment variables,
>>  чтобы было куда ему .module-starter\config  прописывать
>>
>>  , но, предлагаемые Домианом Конвеем модули
>>
>>  use Perl6::Export;
>>  use Perl6::Slurp;
>>  use version;
>>  my $VERSION = qv('0.0.1');
>>  не работают под Win7
>>  https://gist.github.com/1299248
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

--
Nikolay Mishin

From mi на ya.ru  Wed Oct 19 23:58:28 2011
From: mi на ya.ru (Nikolay Mishin)
Date: Thu, 20 Oct 2011 10:58:28 +0400
Subject: [Moscow.pm] Module::Starter::PBP
In-Reply-To: <75647DB0-FBEB-4261-AA5D-85910D7E4908@gmail.com>
References: <414481319050390@web3.yandex.ru>
	<75647DB0-FBEB-4261-AA5D-85910D7E4908@gmail.com>
Message-ID: <615711319093908@web63.yandex.ru>

Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111020/67f73bf0/attachment.html>

From timonnius на gmail.com  Thu Oct 20 00:13:53 2011
From: timonnius на gmail.com (=?KOI8-R?B?9MnNz8bFyiDtwdLLz9c=?=)
Date: Thu, 20 Oct 2011 11:13:53 +0400
Subject: [Moscow.pm] =?koi8-r?b?8NLP18XSy8Eg08/T1M/RzsnRINPF1Mk=?=
In-Reply-To: <CAGYhLe04a6xwuneFbDSdfLHs=3MLzSkJCcnbqAvJgLN7H-AO_w@mail.gmail.com>
References: <CA+7T7RdMPX8_-Mb2EX5+K_Twt9WH7h+u8wQcTwphidTf-kkwSA@mail.gmail.com>
	<1319028176.3531.12.camel@host>
	<CAGYhLe04a6xwuneFbDSdfLHs=3MLzSkJCcnbqAvJgLN7H-AO_w@mail.gmail.com>
Message-ID: <CA+7T7Reo7ubdfiqXS_Z-TtMSW73FYBqV16TQSP+J1QRg4oTnwg@mail.gmail.com>

Спасибо всем, пошел впитывать мудрость вселенского разума.

19 октября 2011 г. 16:44 пользователь Naim Shafiev <shafiev на gmail.com>написал:

> Или же просто по netflow/sflow скорость каптить - те же модули со
> спана или мой любимый nfsen   ,  у вас же они через свитч или раутер
> подрублены между собой  скорее всего
>
> 19 октября 2011 г. 17:42 пользователь Alexey Shrub <worldmind на mail.ru>
> написал:
> > Может пригодится
> > http://iperf.sourceforge.net/
> >
> > On Ср., 2011-10-19 at 15:50 +0400, Тимофей Марков wrote:
> >> Доброго времени суток. Подскажите,  встроенные средства (или модули
> >> cpan) для проверки скорости интернет соединения. Поиск в гугле и
> >> библиотеке CPAN ничего дельного не дал. Если таковых средств нет, буду
> >> благодарен за идею как можно это сделать.
> >> (мне нужно определить скорость канала между четырьмя моими VPS
> >> серверами).
> >> Заранее благодарен всем за ответ. С уважением Тимофей.
> >
> >
> > --
> > Moscow.pm mailing list
> > moscow-pm на pm.org | http://moscow.pm.org
> >
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111020/e71014af/attachment-0001.html>

From postmaster на softsearch.ru  Thu Oct 20 01:21:25 2011
From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=)
Date: Thu, 20 Oct 2011 12:21:25 +0400
Subject: [Moscow.pm] =?koi8-r?b?8NLP18XSy8Eg08/T1M/RzsnRINPF1Mk=?=
In-Reply-To: <CA+7T7RdMPX8_-Mb2EX5+K_Twt9WH7h+u8wQcTwphidTf-kkwSA@mail.gmail.com>
References: <CA+7T7RdMPX8_-Mb2EX5+K_Twt9WH7h+u8wQcTwphidTf-kkwSA@mail.gmail.com>
Message-ID: <865833107.20111020122125@softsearch.ru>

Здравствуйте, Тимофей.

> Доброго  времени суток. Подскажите,  встроенные средства (или модули
> cpan)  для  проверки  скорости  интернет соединения. Поиск в гугле и
> библиотеке  CPAN  ничего  дельного не дал. Если таковых средств нет,
> буду  благодарен за идею как можно это сделать.(мне нужно определить
> скорость канала между четырьмя моими VPS серверами).

Единожды   определить  или  определять  периодически  или  в  реальном
времени? Если последнее, то возможно поможет OS, которая обычно хранит
для   своих   нужд   кэш  с  информацией  о  последних  и/или  текущих
соединениях:  размер  окна,  RTT  и  т.п.  Сие должно выниматься через
sysctl.

-- 
С уважением,
 Михаил                          mailto:postmaster на softsearch.ru


From mi на ya.ru  Thu Oct 20 06:39:50 2011
From: mi на ya.ru (Nikolay Mishin)
Date: Thu, 20 Oct 2011 17:39:50 +0400
Subject: [Moscow.pm] Module::Starter::PBP
In-Reply-To: <4E9F2104.20303@gmail.com>
References: <414481319050390@web3.yandex.ru> <4E9F2104.20303@gmail.com>
Message-ID: <25391319117990@web7.yandex.ru>

Кстати,Ярослав, я не очень понял твоего дополнения в perlcritic.t (https://github.com/yko/module-starter-pbp/blob/master/lib/Module/Starter/PBP.pm#L795 )
ты пытаешься .perlcritic файл искать что ли?


19.10.2011, 23:12, "Yaroslav Korshak" <ykorshak на gmail.com>:
> Привет Николай, привет Moscow.pm
>
> Последние релизы Perl6::Export и Perl6::Slurp - 2004 год. Боюсь, о Win7
> тогда еще не знали, а багрепортов на эти модули никто не открывал.
> Вероятно, Демиан просто не знает о существовании проблемы как таковой.
>
> Хочу также заметить...
> В Module::Starter::PBP есть ряд неприятных огрехов, на которые есть
> тикеты еще с 2005 года и которые так и не были исправлены. Очевидно, что
> у автора нету времени. Поэтому я позволил себе создать github
> репозиторий и исправить в нем наиболее неприятные ошибки:
> https://github.com/yko/module-starter-pbp
> Для начала - те которые касаются тестов (которые будут умирать, если в
> системе не установлен Test::Perl::Critic) и версий в шаблонах.
>
> Замечу, что тикет о проблеме "Breaks on standard windows home
> directories" <https://rt.cpan.org/Public/Bug/Display.html?id=21557>, с
> которой Вы скорее всего имеете дело (HOME),  был открыт в 2006 году:
> https://rt.cpan.org/Public/Bug/Display.html?id=21557.
>
> Возможно, Вы заинтересованы в том, чтобы исправить эту ошибку и написать
> соответствующие тесты.
> Я собираюсь в скорем времени просить у автора применить мои патчи скопом
> или доверить мне права на дальнейшее сопровождение модуля и изменения
> просто войдут в следующую версию модуля.
>
> Что скажете?
>
> --
> Regards
> yko
>
> On 10/19/2011 09:53 PM, Nikolay Mishin wrote:
>
>>  Hi Moscow-pm
>>  Замечательный модуль Module::Starter::PBP https://metacpan.org/module/Module::Starter::PBP
>>
>>  все мне сгенерил как нужно, после
>>  perl -MModule::Starter::PBP=setup
>>  правда пришлось прописывать HOME в system environment variables,
>>  чтобы было куда ему .module-starter\config  прописывать
>>
>>  , но, предлагаемые Домианом Конвеем модули
>>
>>  use Perl6::Export;
>>  use Perl6::Slurp;
>>  use version;
>>  my $VERSION = qv('0.0.1');
>>  не работают под Win7
>>  https://gist.github.com/1299248
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

--
Nikolay Mishin

From ykorshak на gmail.com  Thu Oct 20 07:07:39 2011
From: ykorshak на gmail.com (Yaroslav Korshak)
Date: Thu, 20 Oct 2011 17:07:39 +0300
Subject: [Moscow.pm] Module::Starter::PBP
In-Reply-To: <25391319117990@web7.yandex.ru>
References: <414481319050390@web3.yandex.ru> <4E9F2104.20303@gmail.com>
	<25391319117990@web7.yandex.ru>
Message-ID: <4EA02B2B.6000407@gmail.com>

Николай,
git blame рулит. Этот коммит фиксил rt18293:

https://rt.cpan.org/Public/Bug/Display.html?id=18293

И был основан на предложении THALJEF, собственно, автора Perl::Critic.

Идея автоматически определять наличие perlcriticrc возникла у меня давно 
(меня не покидает чувствуо, что где-то я реализовывал в каком-то из 
своих шаблонов)

*после 20 секунд проверок*

И действительно, я добавил в свобственные шаблоны подобную реализацию 
два месяца назад:
https://github.com/yko/dotfiles/blob/master/.module-starter/PBP/t/perlcritic.t#L12 


Но добавлять подообный функционал или нет я буду решать после обсуждений 
(возможно, с Демианом, если ему будет интересна дальнейшая судьба модуля).
Буду рад услышать твое мнение о этой идее.

--
Regards
yko

On 10/20/2011 04:39 PM, Nikolay Mishin wrote:
> Кстати,Ярослав, я не очень понял твоего дополнения в perlcritic.t (https://github.com/yko/module-starter-pbp/blob/master/lib/Module/Starter/PBP.pm#L795 )
> ты пытаешься .perlcritic файл искать что ли?
>

From mi на ya.ru  Thu Oct 20 09:45:32 2011
From: mi на ya.ru (Nikolay Mishin)
Date: Thu, 20 Oct 2011 20:45:32 +0400
Subject: [Moscow.pm] Module::Starter::PBP
In-Reply-To: <4EA02B2B.6000407@gmail.com>
References: <414481319050390@web3.yandex.ru> <4E9F2104.20303@gmail.com>
	<25391319117990@web7.yandex.ru> <4EA02B2B.6000407@gmail.com>
Message-ID: <79391319129132@web98.yandex.ru>

отлично, кстати насчет $ENV{HOME}

может просто добавить 
на строчку https://github.com/yko/module-starter-pbp/blob/master/lib/Module/Starter/PBP.pm#L148
кусок кода типа такого:

our $is_windows;
$is_windows = ( $^O =~ /MSWin32/ );

if ( ( !defined $ENV{HOME} ) and $is_windows ) {
    $ENV{HOME} = $ENV{USERPROFILE};
}

# Locate the home directory...
if ( !defined $ENV{HOME} ) {
    print 'Please enter the full path of your home directory: ';
    $ENV{HOME} = <>;
    chomp $ENV{HOME};
    croak 'Not a valid directory. Aborting.'
      if !-d $ENV{HOME};
}

правда module-starter все равно ничего не знает о $ENV{USERPROFILE}
и он просто не будет ее использовать,
тут получается нажно и module-starter изменять

20.10.2011, 18:07, "Yaroslav Korshak" <ykorshak на gmail.com>:
> Николай,
> git blame рулит. Этот коммит фиксил rt18293:
>
> https://rt.cpan.org/Public/Bug/Display.html?id=18293
>
> И был основан на предложении THALJEF, собственно, автора Perl::Critic.
>
> Идея автоматически определять наличие perlcriticrc возникла у меня давно
> (меня не покидает чувствуо, что где-то я реализовывал в каком-то из
> своих шаблонов)
>
> *после 20 секунд проверок*
>
> И действительно, я добавил в свобственные шаблоны подобную реализацию
> два месяца назад:
> https://github.com/yko/dotfiles/blob/master/.module-starter/PBP/t/perlcritic.t#L12
>
> Но добавлять подообный функционал или нет я буду решать после обсуждений
> (возможно, с Демианом, если ему будет интересна дальнейшая судьба модуля).
> Буду рад услышать твое мнение о этой идее.
>
> --
> Regards
> yko
>
> On 10/20/2011 04:39 PM, Nikolay Mishin wrote:
>
>>  Кстати,Ярослав, я не очень понял твоего дополнения в perlcritic.t (https://github.com/yko/module-starter-pbp/blob/master/lib/Module/Starter/PBP.pm#L795 )
>>  ты пытаешься .perlcritic файл искать что ли?
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

--
Nikolay Mishin

From meettya на gmail.com  Thu Oct 20 09:55:19 2011
From: meettya на gmail.com (Dmitry Karpich)
Date: Thu, 20 Oct 2011 20:55:19 +0400
Subject: [Moscow.pm] Module::Starter::PBP
In-Reply-To: <79391319129132@web98.yandex.ru>
References: <414481319050390@web3.yandex.ru> <4E9F2104.20303@gmail.com>
	<25391319117990@web7.yandex.ru> <4EA02B2B.6000407@gmail.com>
	<79391319129132@web98.yandex.ru>
Message-ID: <8ECBBE6D-A9E9-4F01-9699-042F1EDACE5E@gmail.com>

Николай, пожалуйста, попробуйте обсудить свои идеи в github, там отличная инфраструктура для этого.

Честно, вот я (лично) не занимаюсь адаптацией модулей под Win-платформу. мне эта тема, ммм.. не очень близка.

Митяй.


On Oct 20, 2011, at 8:45 PM, Nikolay Mishin wrote:

> отлично, кстати насчет $ENV{HOME}
> 


From maxim.vuets на gmail.com  Fri Oct 21 01:09:22 2011
From: maxim.vuets на gmail.com (Maxim Vuets)
Date: Fri, 21 Oct 2011 11:09:22 +0300
Subject: [Moscow.pm] =?koi8-r?b?REFUQSDJIHF1aW5l?=
Message-ID: <CAG6Dboj0cHxdVZoHb=e1dkruwzzJx=5k9ZM0mRi9B1_QDu9sqg@mail.gmail.com>

Привет.

Нужно было несколько раз прочитать DATA (т.е. кусок после __DATA__).
Сделал "seek DATA, 0, 0" и получил весь исходник.
Оказывается, всё гениальное просто: дескриптор DATA представляет файл,
в котором объявлена секция __DATA__, со смещением на оную.

Так получаем куин (quine, программа, которая печатает свой исходный текст):

    seek DATA, 0, 0;
    print do {local $/; <DATA>};
    __DATA__

-- 
Максим Вуец

From mi на ya.ru  Fri Oct 21 01:10:47 2011
From: mi на ya.ru (Nikolay Mishin)
Date: Fri, 21 Oct 2011 12:10:47 +0400
Subject: [Moscow.pm] Module::Starter::PBP
In-Reply-To: <8ECBBE6D-A9E9-4F01-9699-042F1EDACE5E@gmail.com>
References: <414481319050390@web3.yandex.ru> <4E9F2104.20303@gmail.com>
	<25391319117990@web7.yandex.ru> <4EA02B2B.6000407@gmail.com>
	<79391319129132@web98.yandex.ru>
	<8ECBBE6D-A9E9-4F01-9699-042F1EDACE5E@gmail.com>
Message-ID: <303591319184647@web92.yandex.ru>

Да, хорошо, спасибо, действительно там очень удобно переписываться и делать комментарии,
 последую вашему совету.

20.10.2011, 20:55, "Dmitry Karpich" <meettya на gmail.com>:
> Николай, пожалуйста, попробуйте обсудить свои идеи в github, там отличная инфраструктура для этого.
>
> Честно, вот я (лично) не занимаюсь адаптацией модулей под Win-платформу. мне эта тема, ммм.. не очень близка.
>
> Митяй.
>
> On Oct 20, 2011, at 8:45 PM, Nikolay Mishin wrote:
>
>>  отлично, кстати насчет $ENV{HOME}
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

--
Nikolay Mishin

From mi на ya.ru  Fri Oct 21 01:17:31 2011
From: mi на ya.ru (Nikolay Mishin)
Date: Fri, 21 Oct 2011 12:17:31 +0400
Subject: [Moscow.pm] =?koi8-r?b?REFUQSDJIHF1aW5l?=
In-Reply-To: <CAG6Dboj0cHxdVZoHb=e1dkruwzzJx=5k9ZM0mRi9B1_QDu9sqg@mail.gmail.com>
References: <CAG6Dboj0cHxdVZoHb=e1dkruwzzJx=5k9ZM0mRi9B1_QDu9sqg@mail.gmail.com>
Message-ID: <295511319185051@web113.yandex.ru>

Да , хорошая штука http://www.nyx.net/~gthompso/self_perl.txt
особенно open+0;print<0> 

21.10.2011, 12:09, "Maxim Vuets" <maxim.vuets на gmail.com>:
> Привет.
>
> Нужно было несколько раз прочитать DATA (т.е. кусок после __DATA__).
> Сделал "seek DATA, 0, 0" и получил весь исходник.
> Оказывается, всё гениальное просто: дескриптор DATA представляет файл,
> в котором объявлена секция __DATA__, со смещением на оную.
>
> Так получаем куин (quine, программа, которая печатает свой исходный текст):
>
>     seek DATA, 0, 0;
>     print do {local $/; <DATA>};
>     __DATA__
>
> --
> Максим Вуец
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

--
Nikolay Mishin

From timonnius на gmail.com  Fri Oct 21 05:15:48 2011
From: timonnius на gmail.com (=?KOI8-R?B?9MnNz8bFyiDtwdLLz9c=?=)
Date: Fri, 21 Oct 2011 16:15:48 +0400
Subject: [Moscow.pm] =?koi8-r?b?8NLP18XSy8Eg08/T1M/RzsnRINPF1Mk=?=
In-Reply-To: <865833107.20111020122125@softsearch.ru>
References: <CA+7T7RdMPX8_-Mb2EX5+K_Twt9WH7h+u8wQcTwphidTf-kkwSA@mail.gmail.com>
	<865833107.20111020122125@softsearch.ru>
Message-ID: <CA+7T7Rd-R+29q3VVCfy4xOkw+sd7vSgmE7kzRtTdxx2-O7YnkA@mail.gmail.com>

периодически или в реальном времени, не принципиально. Ок буду копать в этом
направлении. спасибо

20 октября 2011 г. 12:21 пользователь Михаил Монашёв <
postmaster на softsearch.ru> написал:

> Здравствуйте, Тимофей.
>
> > Доброго  времени суток. Подскажите,  встроенные средства (или модули
> > cpan)  для  проверки  скорости  интернет соединения. Поиск в гугле и
> > библиотеке  CPAN  ничего  дельного не дал. Если таковых средств нет,
> > буду  благодарен за идею как можно это сделать.(мне нужно определить
> > скорость канала между четырьмя моими VPS серверами).
>
> Единожды   определить  или  определять  периодически  или  в  реальном
> времени? Если последнее, то возможно поможет OS, которая обычно хранит
> для   своих   нужд   кэш  с  информацией  о  последних  и/или  текущих
> соединениях:  размер  окна,  RTT  и  т.п.  Сие должно выниматься через
> sysctl.
>
> --
> С уважением,
>  Михаил                          mailto:postmaster на softsearch.ru
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111021/8a32809a/attachment.html>

From nordicdyno на yandex.ru  Sat Oct 22 04:53:40 2011
From: nordicdyno на yandex.ru (Orlovsky Alexander)
Date: Sat, 22 Oct 2011 15:53:40 +0400
Subject: [Moscow.pm] YAPC::ASIA 2011
Message-ID: <173401319284420@web21.yandex.ru>

Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111022/628006de/attachment.html>

From sharifulin на gmail.com  Sat Oct 22 15:00:17 2011
From: sharifulin на gmail.com (=?KOI8-R?B?4c7B1M/Mycog+8HSycbVzMnO?=)
Date: Sun, 23 Oct 2011 02:00:17 +0400
Subject: [Moscow.pm] YAPC::ASIA 2011
In-Reply-To: <173401319284420@web21.yandex.ru>
References: <173401319284420@web21.yandex.ru>
Message-ID: <CAJG5KK5j0ioAu+NwgqGdue-6_WXmeCO+RQ_1eNSTsYcqphZguw@mail.gmail.com>

Общими усилиями и Андрея Шитова помощью готов перевод презентации Джесси
Винсета Perl 5.16 and beyond.

http://www.slideshare.net/sharifulin/perl-516-and-beyond-by-jesse-vincent



2011/10/22 Orlovsky Alexander <nordicdyno на yandex.ru>

> Не так давно в Токио прошла самая большая Perl-конференция этого года.
> Здесь я набросал дайджест о материалах конференции:
> https://plus.google.com/u/0/107966629974328136037/posts/C7zaDqD6MxL
>
> З.Ы. заодно G+ опробую )
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>


-- 
С уважением,
 Анатолий Шарифулин.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111023/38a44431/attachment.html>

From i.petro.77.00 на gmail.com  Sun Oct 23 01:34:11 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Sun, 23 Oct 2011 12:34:11 +0400
Subject: [Moscow.pm] websocket
Message-ID: <20111023083330.GC14585@apache.rbscorp.ru>

понадобились тут вебсокеты.

нужно иметь дофигища соединений и им рассылать изредка сообщения.

попытался запустить Mojo:: примеры что про IRC, но они не совместимы с
современным браузером. ну да не в этом дело.

мыслится что серверная часть вебсокетов должна работать на событийной
машинке и при этом предоставлять возможность внешней генерации
событий.
то есть нечто вроде такой структуры:

 1. демон принимающий соединения
 
 2. внутренний сокет или порт через который можно с демоном
 соединиться и отправить ему информацию по которой он сплавит
 сообщения одному или нескольким (или никому) присоединенным клиентам.

Вопросы:

 1. а что готовое на эту тему есть?

 2. можно ли вебсокетные соединения пробрасывать через nginx?

From denis.fedoseev на gmail.com  Sun Oct 23 01:36:14 2011
From: denis.fedoseev на gmail.com (Denis Fedoseev)
Date: Sun, 23 Oct 2011 12:36:14 +0400
Subject: [Moscow.pm] websocket
In-Reply-To: <20111023083330.GC14585@apache.rbscorp.ru>
References: <20111023083330.GC14585@apache.rbscorp.ru>
Message-ID: <4225B755-3CB2-4626-A618-3A82C385497A@gmail.com>

https://github.com/vti/pocketio

И вокруг него уже плясать :)

On Oct 23, 2011, at 12:34 PM, Ivan Petrov wrote:

> понадобились тут вебсокеты.
> 
> нужно иметь дофигища соединений и им рассылать изредка сообщения.
> 
> попытался запустить Mojo:: примеры что про IRC, но они не совместимы с
> современным браузером. ну да не в этом дело.
> 
> мыслится что серверная часть вебсокетов должна работать на событийной
> машинке и при этом предоставлять возможность внешней генерации
> событий.
> то есть нечто вроде такой структуры:
> 
> 1. демон принимающий соединения
> 
> 2. внутренний сокет или порт через который можно с демоном
> соединиться и отправить ему информацию по которой он сплавит
> сообщения одному или нескольким (или никому) присоединенным клиентам.
> 
> Вопросы:
> 
> 1. а что готовое на эту тему есть?
> 
> 2. можно ли вебсокетные соединения пробрасывать через nginx?
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org


From aml на rulezz.ru  Sun Oct 23 01:48:16 2011
From: aml на rulezz.ru (Alexander Lourier)
Date: Sun, 23 Oct 2011 12:48:16 +0400
Subject: [Moscow.pm] websocket
In-Reply-To: <20111023083330.GC14585@apache.rbscorp.ru>
References: <20111023083330.GC14585@apache.rbscorp.ru>
Message-ID: <201110231248.16382.aml@rulezz.ru>

В письме Sunday 23 October 2011 12:34:11 Ivan Petrov написал:

> понадобились тут вебсокеты.
> нужно иметь дофигища соединений и им рассылать изредка сообщения.

[skip]

> Вопросы:
>  1. а что готовое на эту тему есть?
>  2. можно ли вебсокетные соединения пробрасывать через nginx?

Есть Dklab Realplexor - http://dklab.ru/lib/dklab_realplexor/

Оно готовое, удобное и написанное на перле. Если понравится, рекомендую свои патчи с багфиксами:
http://forum.dklab.ru/viewtopic.php?t=36149&postdays=0&postorder=asc&start=240
http://forum.dklab.ru/viewtopic.php?t=36149&postdays=0&postorder=asc&start=280

Готовая сборка для Debian пропатченной версии:
http://deb.rulezz.ru/debian/pool/main/r/realplexor/

У автора нет API на перле. Я его частично реализовал (достаточно, чтобы сообщения рассылать по клиентам) - модуль в 
аттаче.

Сокеты отлично пробрасываются через nginx:
server {
        listen *:80;
        server_name rpl.example.com;
        charset off;
        location / {
                proxy_pass http://rpl-server:8088/;
        }
}

-- 
Alexander Lourier, http://aml.rulezz.ru/
----------- следущая часть -----------
A non-text attachment was scrubbed...
Name: Realplexor.pm
Type: application/x-perl
Size: 2416 bytes
Desc: отсутствует
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111023/bc893c36/attachment.bin>

From aml на rulezz.ru  Sun Oct 23 01:56:05 2011
From: aml на rulezz.ru (Alexander Lourier)
Date: Sun, 23 Oct 2011 12:56:05 +0400
Subject: [Moscow.pm] websocket
In-Reply-To: <20111023083330.GC14585@apache.rbscorp.ru>
References: <20111023083330.GC14585@apache.rbscorp.ru>
Message-ID: <201110231256.05165.aml@rulezz.ru>

В письме Sunday 23 October 2011 12:34:11 Ivan Petrov написал:

> понадобились тут вебсокеты.

Пардон. Мой пост не про вебсокеты, а про Ajax long poll. Невнимательно прочитал вопрос. Но, может быть, всё равно 
подойдёт. Тем более, что оно кроссплатформенно и работает даже на утюгах.

-- 
Alexander Lourier, http://aml.rulezz.ru/

From ykorshak на gmail.com  Sun Oct 23 02:28:45 2011
From: ykorshak на gmail.com (Yaroslav Korshak)
Date: Sun, 23 Oct 2011 12:28:45 +0300
Subject: [Moscow.pm] websocket
In-Reply-To: <20111023083330.GC14585@apache.rbscorp.ru>
References: <20111023083330.GC14585@apache.rbscorp.ru>
Message-ID: <4EA3DE4D.7060303@gmail.com>

On 10/23/2011 11:34 AM, Ivan Petrov wrote:
> понадобились тут вебсокеты.
Обратите внимание на состояние документа 
http://dev.w3.org/html5/websockets/ "Editor's Draft 5 October 2011"
<http://dev.w3.org/html5/websockets/>
> нужно иметь дофигища соединений и им рассылать изредка сообщения.
>
> попытался запустить Mojo:: примеры что про IRC, но они не совместимы с
> современным браузером. ну да не в этом дело.
Протокол изменялся и, возможно, будет изменяться в будущем
> мыслится что серверная часть вебсокетов должна работать на событийной
> машинке и при этом предоставлять возможность внешней генерации
> событий.
> то есть нечто вроде такой структуры:
>
>   1. демон принимающий соединения
>
>   2. внутренний сокет или порт через который можно с демоном
>   соединиться и отправить ему информацию по которой он сплавит
>   сообщения одному или нескольким (или никому) присоединенным клиентам.
Вполне решается вебсервисом с (JSON|*) RPC на который при желании можно 
повесить дополнительную вебморду.
> Вопросы:
>
>   1. а что готовое на эту тему есть?
Реализация протокола:
https://metacpan.org/module/Protocol::WebSocket
и соотв. статья автора 
http://showmetheco.de/articles/2011/3/using-protocol-websocket-with-plack.html

Минус в том, что если (когда) снова поменяют черновик, некоторое время 
реализация может быть не стабильной или просто не работать.
Более стабильный вариант - использование SocketIO протокола который 
пытается работать на любых платформах, но при этом использует наилучшую 
из доступных технологий от WebSocket до Forever Iframe и JSONP Polling.
Описание совместимости и поддерживаемых протоколов тут: 
http://socket.io/#browser-support
Для Perl, как уже написал Денис, есть реализация которая называется 
PocketIO, которая использует в том числе Protocol::WebSocket
Чтобы узнать немного больше, можно почитать статью автора: 
http://showmetheco.de/articles/2011/9/pocketio-realtime-applications-for-plack.html 
ну и документацию на socket.io

Насколько мне известно, PocketIO использовалась в реальном проекте с 
достаточно большой нагрузкой.

Плюс в поддержке большого количества платформ/клиентов. Минус в более 
сложном разворачивании приложения.
>   2. можно ли вебсокетные соединения пробрасывать через nginx?
nginx_tcp_proxy_module
http://habrahabr.ru/blogs/nginx/124089/

Возможно, сейчас есть решения и лучше, я некоторое время не следил за 
ситуацией вокруг WebSocket

--
Regards
yko
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111023/28624cf5/attachment-0001.html>

From akzhan.abdulin на gmail.com  Sun Oct 23 06:26:09 2011
From: akzhan.abdulin на gmail.com (Akzhan Abdulin)
Date: Sun, 23 Oct 2011 17:26:09 +0400
Subject: [Moscow.pm] websocket
In-Reply-To: <20111023083330.GC14585@apache.rbscorp.ru>
References: <20111023083330.GC14585@apache.rbscorp.ru>
Message-ID: <CAGOcgF2EBXqq5Q0faBD1eyyueEeS8=TXMyjk+u8Axe=Sr=Xk=Q@mail.gmail.com>

Для этого.
1) лучший инструмент - Node.JS (Faye)
2) вместо nginx надо смотреть HA Proxy. nginx пока не поддерживает
WebSockets.

23 октября 2011 г. 12:34 пользователь Ivan Petrov
<i.petro.77.00 на gmail.com>написал:

> понадобились тут вебсокеты.
>
> нужно иметь дофигища соединений и им рассылать изредка сообщения.
>
> попытался запустить Mojo:: примеры что про IRC, но они не совместимы с
> современным браузером. ну да не в этом дело.
>
> мыслится что серверная часть вебсокетов должна работать на событийной
> машинке и при этом предоставлять возможность внешней генерации
> событий.
> то есть нечто вроде такой структуры:
>
>  1. демон принимающий соединения
>
>  2. внутренний сокет или порт через который можно с демоном
>  соединиться и отправить ему информацию по которой он сплавит
>  сообщения одному или нескольким (или никому) присоединенным клиентам.
>
> Вопросы:
>
>  1. а что готовое на эту тему есть?
>
>  2. можно ли вебсокетные соединения пробрасывать через nginx?
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111023/317c18a6/attachment.html>

From dsimonov на gmail.com  Mon Oct 24 00:14:45 2011
From: dsimonov на gmail.com (Dmitry Simonov)
Date: Mon, 24 Oct 2011 11:14:45 +0400
Subject: [Moscow.pm] websocket
In-Reply-To: <CAGOcgF2EBXqq5Q0faBD1eyyueEeS8=TXMyjk+u8Axe=Sr=Xk=Q@mail.gmail.com>
References: <20111023083330.GC14585@apache.rbscorp.ru>
	<CAGOcgF2EBXqq5Q0faBD1eyyueEeS8=TXMyjk+u8Axe=Sr=Xk=Q@mail.gmail.com>
Message-ID: <CAL9wMxUMYQ5X7fPt+gynB=xzAw9cQaVrGmHbY_EuV0cNbyevyw@mail.gmail.com>

Не смущай наро, Акжан.

1. Node.js: http://habrahabr.ru/blogs/nodejs/129640/
2. Nginx: http://mdounin.ru/hg/ngx_http_upstream_keepalive/

---
Dmitriy V. Simonov,
Perl & Python programmer



2011/10/23 Akzhan Abdulin <akzhan.abdulin на gmail.com>:
> Для этого.
> 1) лучший инструмент - Node.JS (Faye)
> 2) вместо nginx надо смотреть HA Proxy. nginx пока не поддерживает
> WebSockets.
>

From dsimonov на gmail.com  Mon Oct 24 00:18:55 2011
From: dsimonov на gmail.com (Dmitry Simonov)
Date: Mon, 24 Oct 2011 11:18:55 +0400
Subject: [Moscow.pm] websocket
In-Reply-To: <20111023083330.GC14585@apache.rbscorp.ru>
References: <20111023083330.GC14585@apache.rbscorp.ru>
Message-ID: <CAL9wMxWz630mFeBftjhOG+hB8HqSrBeQdMOx9608SWqp=v+fEQ@mail.gmail.com>

http://cpansearch.perl.org/src/SRI/Mojolicious-2.09/t/mojolicious/websocket_lite_app.t

---
Dmitriy V. Simonov,
Perl & Python programmer



2011/10/23 Ivan Petrov <i.petro.77.00 на gmail.com>:
> понадобились тут вебсокеты.
> нужно иметь дофигища соединений и им рассылать изредка сообщения.

From dsimonov на gmail.com  Mon Oct 24 00:33:21 2011
From: dsimonov на gmail.com (Dmitry Simonov)
Date: Mon, 24 Oct 2011 11:33:21 +0400
Subject: [Moscow.pm] =?utf-8?b?0J/RgNC+0LLQtdGA0LrQsCDRgdC+0YHRgtC+0Y8=?=
	=?utf-8?b?0L3QuNGPINGB0LXRgtC4?=
In-Reply-To: <1319028176.3531.12.camel@host>
References: <CA+7T7RdMPX8_-Mb2EX5+K_Twt9WH7h+u8wQcTwphidTf-kkwSA@mail.gmail.com>
	<1319028176.3531.12.camel@host>
Message-ID: <CAL9wMxVE+fEhciJejBtcGO1J9Mh8Zoqx_H_RRyL84yFon9YSEA@mail.gmail.com>

Это true-way, Тимофей. Запускаешь сервера на проверяемых железках и
клиентам (скажем по крону) простукиваешь их. Ни в коем случае не делай
это синхронно через интерфейс, - положишь всё нафиг. Делай асинхронно.

---
Dmitriy V. Simonov,
Perl & Python programmer



2011/10/19 Alexey Shrub <worldmind на mail.ru>:
> Может пригодится
> http://iperf.sourceforge.net/

From sharifulin на gmail.com  Mon Oct 24 01:21:12 2011
From: sharifulin на gmail.com (=?KOI8-R?B?4c7B1M/Mycog+8HSycbVzMnO?=)
Date: Mon, 24 Oct 2011 12:21:12 +0400
Subject: [Moscow.pm] websocket
In-Reply-To: <CAL9wMxWz630mFeBftjhOG+hB8HqSrBeQdMOx9608SWqp=v+fEQ@mail.gmail.com>
References: <20111023083330.GC14585@apache.rbscorp.ru>
	<CAL9wMxWz630mFeBftjhOG+hB8HqSrBeQdMOx9608SWqp=v+fEQ@mail.gmail.com>
Message-ID: <CAJG5KK6ODKtV387+9FiiZn4fLBF5P4ouKnMW9vbLxf2-=ie7hg@mail.gmail.com>

Могу порекомендовать Event Mashine, работает поверх HTTP, в моджо уже
реализовано. Но сам не проверял в бою.


On Monday, October 24, 2011, Dmitry Simonov <dsimonov на gmail.com> wrote:
>
http://cpansearch.perl.org/src/SRI/Mojolicious-2.09/t/mojolicious/websocket_lite_app.t
>
> ---
> Dmitriy V. Simonov,
> Perl & Python programmer
>
>
>
> 2011/10/23 Ivan Petrov <i.petro.77.00 на gmail.com>:
>> понадобились тут вебсокеты.
>> нужно иметь дофигища соединений и им рассылать изредка сообщения.
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>

-- 
С уважением,
 Анатолий Шарифулин.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111024/f65e5bff/attachment.html>

From akzhan.abdulin на gmail.com  Mon Oct 24 01:59:06 2011
From: akzhan.abdulin на gmail.com (Akzhan Abdulin)
Date: Mon, 24 Oct 2011 12:59:06 +0400
Subject: [Moscow.pm] websocket
In-Reply-To: <CAL9wMxUMYQ5X7fPt+gynB=xzAw9cQaVrGmHbY_EuV0cNbyevyw@mail.gmail.com>
References: <20111023083330.GC14585@apache.rbscorp.ru>
	<CAGOcgF2EBXqq5Q0faBD1eyyueEeS8=TXMyjk+u8Axe=Sr=Xk=Q@mail.gmail.com>
	<CAL9wMxUMYQ5X7fPt+gynB=xzAw9cQaVrGmHbY_EuV0cNbyevyw@mail.gmail.com>
Message-ID: <CAGOcgF1LepMetTGcvVz7noX9ZXVQmmnW4K-W-N5tbCnJ+3iW3g@mail.gmail.com>

1) статья - толстый троллинг. Этак можно обхаять и POE, к примеру :)
более грамотная критика здесь - http://habrahabr.ru/blogs/nodejs/127696/

2) это вообще-то не Web Sockets, судя по README.


24 октября 2011 г. 11:14 пользователь Dmitry Simonov
<dsimonov на gmail.com>написал:

> Не смущай наро, Акжан.
>
> 1. Node.js: http://habrahabr.ru/blogs/nodejs/129640/
> 2. Nginx: http://mdounin.ru/hg/ngx_http_upstream_keepalive/
>
> ---
> Dmitriy V. Simonov,
> Perl & Python programmer
>
>
>
> 2011/10/23 Akzhan Abdulin <akzhan.abdulin на gmail.com>:
> > Для этого.
> > 1) лучший инструмент - Node.JS (Faye)
> > 2) вместо nginx надо смотреть HA Proxy. nginx пока не поддерживает
> > WebSockets.
> >
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111024/02a280dc/attachment.html>

From mi на ya.ru  Mon Oct 24 02:06:51 2011
From: mi на ya.ru (Nikolay Mishin)
Date: Mon, 24 Oct 2011 13:06:51 +0400
Subject: [Moscow.pm] YAPC::ASIA 2011
In-Reply-To: <CAJG5KK5j0ioAu+NwgqGdue-6_WXmeCO+RQ_1eNSTsYcqphZguw@mail.gmail.com>
References: <173401319284420@web21.yandex.ru>
	<CAJG5KK5j0ioAu+NwgqGdue-6_WXmeCO+RQ_1eNSTsYcqphZguw@mail.gmail.com>
Message-ID: <429271319447212@web120.yandex.ru>

Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111024/424ea7ec/attachment-0001.html>

From evdokimov.denis на gmail.com  Mon Oct 24 08:52:01 2011
From: evdokimov.denis на gmail.com (Denis Evdokimov)
Date: Mon, 24 Oct 2011 19:52:01 +0400
Subject: [Moscow.pm] YAPC::ASIA 2011
In-Reply-To: <429271319447212@web120.yandex.ru>
References: <173401319284420@web21.yandex.ru>
	<CAJG5KK5j0ioAu+NwgqGdue-6_WXmeCO+RQ_1eNSTsYcqphZguw@mail.gmail.com>
	<429271319447212@web120.yandex.ru>
Message-ID: <CAFdXSm9P2yOQ_RDdn4fQrP2ew2pvbtSX4Y2hWokfxtx4T5aWww@mail.gmail.com>

Благодарю за труд.
Очень приятно было это прочитать.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111024/abab290a/attachment.html>

From dsimonov на gmail.com  Mon Oct 24 21:40:02 2011
From: dsimonov на gmail.com (Dmitry Simonov)
Date: Tue, 25 Oct 2011 08:40:02 +0400
Subject: [Moscow.pm] websocket
In-Reply-To: <CAGOcgF1LepMetTGcvVz7noX9ZXVQmmnW4K-W-N5tbCnJ+3iW3g@mail.gmail.com>
References: <20111023083330.GC14585@apache.rbscorp.ru>
	<CAGOcgF2EBXqq5Q0faBD1eyyueEeS8=TXMyjk+u8Axe=Sr=Xk=Q@mail.gmail.com>
	<CAL9wMxUMYQ5X7fPt+gynB=xzAw9cQaVrGmHbY_EuV0cNbyevyw@mail.gmail.com>
	<CAGOcgF1LepMetTGcvVz7noX9ZXVQmmnW4K-W-N5tbCnJ+3iW3g@mail.gmail.com>
Message-ID: <CAL9wMxXzm8Pw6usTnt72YQgmG0=cBpfL1pjaY420aAuVSg9e1Q@mail.gmail.com>

Учи матчасть, Акжан. Вебсокеты используют http 1.1 и keepalive, а
модуль Макса Дунина это "Keepalive balancer module for nginx".

Node.js - это такое же зло, как и php. Мне тут на днях объясняли
отличия от собеседующегося php-шник и perl-овика. Если искать первых,
то приходит масса школьников и ни одного тёртого калача. Если искать
вторых, то не приходит ни кто. Но если уж приходит, то это уже сразу
тёртый калач.

А лучше учи сразу питон :)

П.С. о, господи, только прошу не разводить тут срач и холивор по
поводу перла, пхп и питона. Это я так. К слову :)

---
Dmitriy V. Simonov,
Perl & Python programmer



2011/10/24 Akzhan Abdulin <akzhan.abdulin на gmail.com>:
> 1) статья - толстый троллинг. Этак можно обхаять и POE, к примеру :)
> более грамотная критика здесь - http://habrahabr.ru/blogs/nodejs/127696/
> 2) это вообще-то не Web Sockets, судя по README.

From sharifulin на gmail.com  Mon Oct 24 21:45:39 2011
From: sharifulin на gmail.com (=?KOI8-R?B?4c7B1M/Mycog+8HSycbVzMnO?=)
Date: Tue, 25 Oct 2011 08:45:39 +0400
Subject: [Moscow.pm] websocket
In-Reply-To: <CAL9wMxXzm8Pw6usTnt72YQgmG0=cBpfL1pjaY420aAuVSg9e1Q@mail.gmail.com>
References: <20111023083330.GC14585@apache.rbscorp.ru>
	<CAGOcgF2EBXqq5Q0faBD1eyyueEeS8=TXMyjk+u8Axe=Sr=Xk=Q@mail.gmail.com>
	<CAL9wMxUMYQ5X7fPt+gynB=xzAw9cQaVrGmHbY_EuV0cNbyevyw@mail.gmail.com>
	<CAGOcgF1LepMetTGcvVz7noX9ZXVQmmnW4K-W-N5tbCnJ+3iW3g@mail.gmail.com>
	<CAL9wMxXzm8Pw6usTnt72YQgmG0=cBpfL1pjaY420aAuVSg9e1Q@mail.gmail.com>
Message-ID: <CAJG5KK7Rg115GJv3jrhPbC3kLVss=Oev-Yu2u4esR5cVdGQyOw@mail.gmail.com>

То есть ты чёткий тролль? :)

On Tuesday, October 25, 2011, Dmitry Simonov <dsimonov на gmail.com> wrote:
> Учи матчасть, Акжан. Вебсокеты используют http 1.1 и keepalive, а
> модуль Макса Дунина это "Keepalive balancer module for nginx".
>
> Node.js - это такое же зло, как и php. Мне тут на днях объясняли
> отличия от собеседующегося php-шник и perl-овика. Если искать первых,
> то приходит масса школьников и ни одного тёртого калача. Если искать
> вторых, то не приходит ни кто. Но если уж приходит, то это уже сразу
> тёртый калач.
>
> А лучше учи сразу питон :)
>
> П.С. о, господи, только прошу не разводить тут срач и холивор по
> поводу перла, пхп и питона. Это я так. К слову :)
>
> ---
> Dmitriy V. Simonov,
> Perl & Python programmer
>
>
>
> 2011/10/24 Akzhan Abdulin <akzhan.abdulin на gmail.com>:
>> 1) статья - толстый троллинг. Этак можно обхаять и POE, к примеру :)
>> более грамотная критика здесь - http://habrahabr.ru/blogs/nodejs/127696/
>> 2) это вообще-то не Web Sockets, судя по README.
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>

-- 
С уважением,
 Анатолий Шарифулин.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111025/69b68cf0/attachment.html>

From dsimonov на gmail.com  Mon Oct 24 21:48:59 2011
From: dsimonov на gmail.com (Dmitry Simonov)
Date: Tue, 25 Oct 2011 08:48:59 +0400
Subject: [Moscow.pm] websocket
In-Reply-To: <CAJG5KK7Rg115GJv3jrhPbC3kLVss=Oev-Yu2u4esR5cVdGQyOw@mail.gmail.com>
References: <20111023083330.GC14585@apache.rbscorp.ru>
	<CAGOcgF2EBXqq5Q0faBD1eyyueEeS8=TXMyjk+u8Axe=Sr=Xk=Q@mail.gmail.com>
	<CAL9wMxUMYQ5X7fPt+gynB=xzAw9cQaVrGmHbY_EuV0cNbyevyw@mail.gmail.com>
	<CAGOcgF1LepMetTGcvVz7noX9ZXVQmmnW4K-W-N5tbCnJ+3iW3g@mail.gmail.com>
	<CAL9wMxXzm8Pw6usTnt72YQgmG0=cBpfL1pjaY420aAuVSg9e1Q@mail.gmail.com>
	<CAJG5KK7Rg115GJv3jrhPbC3kLVss=Oev-Yu2u4esR5cVdGQyOw@mail.gmail.com>
Message-ID: <CAL9wMxUB2s4PQnMdD27Wc9rwY+J6drFc4PMSdUzVVcMryg9dVw@mail.gmail.com>

Не "чёткий", а "тот ещё" :)

---
Dmitriy V. Simonov,
Perl & Python programmer



2011/10/25 Анатолий Шарифулин <sharifulin на gmail.com>:
> То есть ты чёткий тролль? :)

From dmitry на karasik.eu.org  Mon Oct 24 22:08:34 2011
From: dmitry на karasik.eu.org (Dmitry Karasik)
Date: Tue, 25 Oct 2011 07:08:34 +0200
Subject: [Moscow.pm] websocket
In-Reply-To: <CAL9wMxXzm8Pw6usTnt72YQgmG0=cBpfL1pjaY420aAuVSg9e1Q@mail.gmail.com>
References: <20111023083330.GC14585@apache.rbscorp.ru>
	<CAGOcgF2EBXqq5Q0faBD1eyyueEeS8=TXMyjk+u8Axe=Sr=Xk=Q@mail.gmail.com>
	<CAL9wMxUMYQ5X7fPt+gynB=xzAw9cQaVrGmHbY_EuV0cNbyevyw@mail.gmail.com>
	<CAGOcgF1LepMetTGcvVz7noX9ZXVQmmnW4K-W-N5tbCnJ+3iW3g@mail.gmail.com>
	<CAL9wMxXzm8Pw6usTnt72YQgmG0=cBpfL1pjaY420aAuVSg9e1Q@mail.gmail.com>
Message-ID: <20111025050834.GA96650@tetsuo.karasik.eu.org>


> Node.js - это такое же зло, как и php. 

<philosophy mode on>

По теме сказать ничего не имею, но я тут по работе иногда смотрю в исходники 
на древних языках, спасибо господи что я не программист mainframe...
php после кобола дорогой друг товарищ и брат )
Миритесь скорее )) 

> А лучше учи сразу питон :)
> П.С. о, господи, только прошу не разводить тут срач и холивор по
> поводу перла, пхп и питона. Это я так. К слову :)



-- 
Sincerely,
	Dmitry Karasik


From akzhan.abdulin на gmail.com  Mon Oct 24 22:34:02 2011
From: akzhan.abdulin на gmail.com (Akzhan Abdulin)
Date: Tue, 25 Oct 2011 09:34:02 +0400
Subject: [Moscow.pm] websocket
In-Reply-To: <CAL9wMxXzm8Pw6usTnt72YQgmG0=cBpfL1pjaY420aAuVSg9e1Q@mail.gmail.com>
References: <20111023083330.GC14585@apache.rbscorp.ru>
	<CAGOcgF2EBXqq5Q0faBD1eyyueEeS8=TXMyjk+u8Axe=Sr=Xk=Q@mail.gmail.com>
	<CAL9wMxUMYQ5X7fPt+gynB=xzAw9cQaVrGmHbY_EuV0cNbyevyw@mail.gmail.com>
	<CAGOcgF1LepMetTGcvVz7noX9ZXVQmmnW4K-W-N5tbCnJ+3iW3g@mail.gmail.com>
	<CAL9wMxXzm8Pw6usTnt72YQgmG0=cBpfL1pjaY420aAuVSg9e1Q@mail.gmail.com>
Message-ID: <CAGOcgF15Pnq5enYuuNJxMHYhSSAHbDyWH3xPOEzT8OJA5jib_g@mail.gmail.com>

Для меня было новостью, что появился модуль для общения с бэкендами по
http/1.1. Спасибо.
Буду смотреть :)

P.S.: насчет Node ты неправ. Очень стабильно себя ведёт у нас в production.

25 октября 2011 г. 8:40 пользователь Dmitry Simonov <dsimonov на gmail.com>написал:

> Учи матчасть, Акжан. Вебсокеты используют http 1.1 и keepalive, а
> модуль Макса Дунина это "Keepalive balancer module for nginx".
>
> Node.js - это такое же зло, как и php. Мне тут на днях объясняли
> отличия от собеседующегося php-шник и perl-овика. Если искать первых,
> то приходит масса школьников и ни одного тёртого калача. Если искать
> вторых, то не приходит ни кто. Но если уж приходит, то это уже сразу
> тёртый калач.
>
> А лучше учи сразу питон :)
>
> П.С. о, господи, только прошу не разводить тут срач и холивор по
> поводу перла, пхп и питона. Это я так. К слову :)
>
> ---
> Dmitriy V. Simonov,
> Perl & Python programmer
>
>
>
> 2011/10/24 Akzhan Abdulin <akzhan.abdulin на gmail.com>:
> > 1) статья - толстый троллинг. Этак можно обхаять и POE, к примеру :)
> > более грамотная критика здесь - http://habrahabr.ru/blogs/nodejs/127696/
> > 2) это вообще-то не Web Sockets, судя по README.
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111025/49fd9e61/attachment-0001.html>

From peter на vereshagin.org  Tue Oct 25 07:22:14 2011
From: peter на vereshagin.org (Peter Vereshagin)
Date: Tue, 25 Oct 2011 18:22:14 +0400
Subject: [Moscow.pm] =?koi8-r?b?y8/NzcXO1NkgwdfUz9XLzMHE3snLz80g1yBwb2Q=?=
Message-ID: <20111025142214.GC5547@external.screwed.box>

Hello.

Есть желание из этого:

    # Function
    # Performs counteractions strikeablity ...
    # Takes     :   arg0, arg1, ...
    # Returns   :   value of acting ...
    sub abcd_efgh {
        ...
    }

понаделать  айтемы для пода:

    =head1 METHODS AND FUNCTIONS

    =item abcd_efgh

    Function. Performs counteractions strikeablity ...

    Takes:  arg0, arg1, ...

    Returns: value ...

или как-то так. Собственно, вопросы:

    - в отдельный .pod класть или после __END__ лучше?
    - что есть на эту тему готовое?
    - если Pod::Weaver, то чем в нём делать именно это? конкретно плагин там
      или не нашёл или их там слишком много.

этот подвивер, вообще, без Dist::Zilla юзабелен?

--
Peter Vereshagin <peter на vereshagin.org> (http://vereshagin.org) pgp: A0E26627 

From andy на shitov.ru  Tue Oct 25 15:03:34 2011
From: andy на shitov.ru (Andrew Shitov)
Date: Wed, 26 Oct 2011 00:03:34 +0200
Subject: [Moscow.pm] Saint Perl - 3
Message-ID: <CANTXRvRjGu1jFwNMR0LJi1Ku-xiUbHRMUs3P247L5g-_px+vHg@mail.gmail.com>

Позвольте просто процитировать интернеты. Не успел появиться анонс, а
про нас уже пишет зарубежная пресса
(http://perl-nachrichten.de/index.cgi/details/973):

"Saint Perl" 2011 am 18. Dezember
Am 18. Dezember 2011 findet in Sankt Petersburg (Russland) die 3.
Ausgabe von "Saint Perl" statt.
Die Teilnahme an der Veranstaltung ist kostenlos. Wer einen Vortrag
einreichen m?chte, kann dies ?ber die Webseite tun.

В третий раз мы приглашаем всех на День рождения перла в
Санкт-Петербург. 18 декабря на уже третий (и по-прежнему бесплатный)
Perl-воркшоп в этот день в этом городе:
http://event.perlrussia.org/saintperl3/.

--
Andrew Shitov
______________________________________________________________________
andy на shitov.ru | http://shitov.ru

From ruz на bestpractical.com  Tue Oct 25 16:45:42 2011
From: ruz на bestpractical.com (Ruslan Zakirov)
Date: Wed, 26 Oct 2011 03:45:42 +0400
Subject: [Moscow.pm] Saint Perl - 3
In-Reply-To: <CANTXRvRjGu1jFwNMR0LJi1Ku-xiUbHRMUs3P247L5g-_px+vHg@mail.gmail.com>
References: <CANTXRvRjGu1jFwNMR0LJi1Ku-xiUbHRMUs3P247L5g-_px+vHg@mail.gmail.com>
Message-ID: <CAMOxC8uQSytpLFGhTbZhMmHK5-AqRmAz7pYo+TA45MTz7D1ZyQ@mail.gmail.com>

А где venue?

2011/10/26 Andrew Shitov <andy на shitov.ru>:
> Позвольте просто процитировать интернеты. Не успел появиться анонс, а
> про нас уже пишет зарубежная пресса
> (http://perl-nachrichten.de/index.cgi/details/973):
>
> "Saint Perl" 2011 am 18. Dezember
> Am 18. Dezember 2011 findet in Sankt Petersburg (Russland) die 3.
> Ausgabe von "Saint Perl" statt.
> Die Teilnahme an der Veranstaltung ist kostenlos. Wer einen Vortrag
> einreichen m?chte, kann dies ?ber die Webseite tun.
>
> В третий раз мы приглашаем всех на День рождения перла в
> Санкт-Петербург. 18 декабря на уже третий (и по-прежнему бесплатный)
> Perl-воркшоп в этот день в этом городе:
> http://event.perlrussia.org/saintperl3/.
>
> --
> Andrew Shitov
> ______________________________________________________________________
> andy на shitov.ru | http://shitov.ru
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
Best regards, Ruslan.

From i.petro.77.00 на gmail.com  Wed Oct 26 00:09:58 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Wed, 26 Oct 2011 11:09:58 +0400
Subject: [Moscow.pm] Module::Loaded
Message-ID: <20111026070957.GE14585@apache.rbscorp.ru>

нужно написать некий функционал в стиле 'use base "Module"';

соответственно хочется чтобы этот модуль делал 'require Module'.

вроде все просто, однако хочется чтобы работало и с пакетами, которые
не выделены в модули

если пишем

use Module::Loaded;
use Module::Load;

unless (loaded $module) {
    load $module;
}

то load естественно обламывается в случае если передается имя пакета,
который определен прямо в main::.

Понятно что можно поглядеть в пространство имен есть ли уже такой
пакет или нет.

но вот интересно, может стандартное есть что-то на эту тему чтобы
велосипед не городить?

From mi на ya.ru  Wed Oct 26 01:01:48 2011
From: mi на ya.ru (Nikolay Mishin)
Date: Wed, 26 Oct 2011 12:01:48 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?y8/NzcXO1NkgwdfUz9XLzMHE3snLz80g1yBwb2Q=?=
In-Reply-To: <20111025142214.GC5547@external.screwed.box>
References: <20111025142214.GC5547@external.screwed.box>
Message-ID: <60021319616108@web77.yandex.ru>

Супер идея, давно о таком мечтаю,
мне кажется после __END__ в модуле самое то, вот еще бы
сделать так, чтобы скрипт проходит по текущему скрипту и генерил такие поды на основе текущих функций, превращая комменты к функции
#show current cursor from db
sub say_values_from_db {
    my $sth     = shift;#sql result
    my $db_conn = shift;#connect to prod1.db
..
   return \%values;#pure perl values from db
}

в pod доку

25.10.2011, 18:22, "Peter Vereshagin" <peter на vereshagin.org>:
> Hello.
>
> Есть желание из этого:
>
>     # Function
>     # Performs counteractions strikeablity ...
>     # Takes     :   arg0, arg1, ...
>     # Returns   :   value of acting ...
>     sub abcd_efgh {
>         ...
>     }
>
> понаделать  айтемы для пода:
>
>     =head1 METHODS AND FUNCTIONS
>
>     =item abcd_efgh
>
>     Function. Performs counteractions strikeablity ...
>
>     Takes:  arg0, arg1, ...
>
>     Returns: value ...
>
> или как-то так. Собственно, вопросы:
>
>     - в отдельный .pod класть или после __END__ лучше?
>     - что есть на эту тему готовое?
>     - если Pod::Weaver, то чем в нём делать именно это? конкретно плагин там
>       или не нашёл или их там слишком много.
>
> этот подвивер, вообще, без Dist::Zilla юзабелен?
>
> --
> Peter Vereshagin <peter на vereshagin.org> (http://vereshagin.org) pgp: A0E26627
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

--
Nikolay Mishin

From mi на ya.ru  Wed Oct 26 01:31:15 2011
From: mi на ya.ru (Nikolay Mishin)
Date: Wed, 26 Oct 2011 12:31:15 +0400
Subject: [Moscow.pm] =?koi8-r?b?9MXT1MnS1cXNICDeydPMzyDCz8zY28UgyczJIM3F?=
	=?koi8-r?b?ztjbxSwgzs8gzsUgzcXOxcUgLCDexc0gzsEgMTAg0NLPw8XO1M/X?=
Message-ID: <21971319617878@web64.yandex.ru>

Moscow-pm, Hi

как вам такая реализация?
use 5.01;
use Test::More qw/no_plan/;
use POSIX;
my $calc_value = 22;
my $orig_value = 23;
my $persent    = 10;      #%
my $message    = 'BIG_SYSTEM';

test_10_persent( $calc_value, $orig_value, $persent, $message );

#test if bigger or lower not lower then 10%
sub test_10_persent {
    my ( $calc_value, $orig_value, $persent, $message ) = @_;

    if ( $calc_value >= $orig_value ) {
        cmp_ok( $calc_value, '>=', $orig_value,
            $message . " $calc_value >= $orig_value " );
    }
    else {
        my $cal_persent =
          floor( abs( ( ( $calc_value - $orig_value ) / $orig_value ) * 100 ) );
        cmp_ok( $cal_persent, '<=', $persent,
            $message . " $calc_value <= $orig_value but not lower then 10 %" );
    }
}


--
Nikolay Mishin

From somerandomlogin на gmail.com  Wed Oct 26 02:10:53 2011
From: somerandomlogin на gmail.com (Jack of Shadows)
Date: Wed, 26 Oct 2011 13:10:53 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?9MXT1MnS1cXNIN7J08zPIMLPzNjbxSDJzMkgzcXO?=
	=?koi8-r?b?2NvFLCDOzyDOxSDNxc7FxSAsIN7FzSDOwSAxMCDQ0s/Dxc7Uz9c=?=
In-Reply-To: <21971319617878@web64.yandex.ru>
References: <21971319617878@web64.yandex.ru>
Message-ID: <CAH1e3-f1A-2wAc8MmJKdXnOXVcxNohZ9pqYc_TS3Fk-Cz2BtcQ@mail.gmail.com>

<grammar-nazi>Percent.</grammar-nazi>
:-)

2011/10/26 Nikolay Mishin <mi на ya.ru>:
> Moscow-pm, Hi
>
> как вам такая реализация?
> use 5.01;
> use Test::More qw/no_plan/;
> use POSIX;
> my $calc_value = 22;
> my $orig_value = 23;
> my $persent    = 10;      #%
> my $message    = 'BIG_SYSTEM';
>
> test_10_persent( $calc_value, $orig_value, $persent, $message );
>
> #test if bigger or lower not lower then 10%
> sub test_10_persent {
>    my ( $calc_value, $orig_value, $persent, $message ) = @_;
>
>    if ( $calc_value >= $orig_value ) {
>        cmp_ok( $calc_value, '>=', $orig_value,
>            $message . " $calc_value >= $orig_value " );
>    }
>    else {
>        my $cal_persent =
>          floor( abs( ( ( $calc_value - $orig_value ) / $orig_value ) * 100 ) );
>        cmp_ok( $cal_persent, '<=', $persent,
>            $message . " $calc_value <= $orig_value but not lower then 10 %" );
>    }
> }
>
>
> --
> Nikolay Mishin
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>

From andy на shitov.ru  Wed Oct 26 02:19:02 2011
From: andy на shitov.ru (Andrew Shitov)
Date: Wed, 26 Oct 2011 11:19:02 +0200
Subject: [Moscow.pm] Saint Perl - 3
In-Reply-To: <CAMOxC8uQSytpLFGhTbZhMmHK5-AqRmAz7pYo+TA45MTz7D1ZyQ@mail.gmail.com>
References: <CANTXRvRjGu1jFwNMR0LJi1Ku-xiUbHRMUs3P247L5g-_px+vHg@mail.gmail.com>
	<CAMOxC8uQSytpLFGhTbZhMmHK5-AqRmAz7pYo+TA45MTz7D1ZyQ@mail.gmail.com>
Message-ID: <CANTXRvTOyrCeMQudO52uJZv91vs5xpPK=jOVknQ8XHZmfN7WpA@mail.gmail.com>

> А где venue?

На днях будет адрес.

-- 
Andrew Shitov
______________________________________________________________________
andy на shitov.ru | http://shitov.ru

From akzhan.abdulin на gmail.com  Wed Oct 26 03:36:46 2011
From: akzhan.abdulin на gmail.com (Akzhan Abdulin)
Date: Wed, 26 Oct 2011 14:36:46 +0400
Subject: [Moscow.pm] =?utf-8?b?0KLQtdGB0YLQuNGA0YPQtdC8INGH0LjRgdC70L4g?=
	=?utf-8?b?0LHQvtC70YzRiNC1INC40LvQuCDQvNC10L3RjNGI0LUsINC90L4g0L0=?=
	=?utf-8?b?0LUg0LzQtdC90LXQtSAsINGH0LXQvCDQvdCwIDEwINC/0YDQvtGG0LU=?=
	=?utf-8?b?0L3RgtC+0LI=?=
In-Reply-To: <21971319617878@web64.yandex.ru>
References: <21971319617878@web64.yandex.ru>
Message-ID: <CAGOcgF2n9JjgJXEMGckuxT1gqzKdQZQu8UGFN_0pW-RYpGwaNA@mail.gmail.com>

test_relative_difference или что-нибудь в этом духе? И, понятно, $percentage
хотелось бы задавать.

26 октября 2011 г. 12:31 пользователь Nikolay Mishin <mi на ya.ru> написал:

> Moscow-pm, Hi
>
> как вам такая реализация?
> use 5.01;
> use Test::More qw/no_plan/;
> use POSIX;
> my $calc_value = 22;
> my $orig_value = 23;
> my $persent    = 10;      #%
> my $message    = 'BIG_SYSTEM';
>
> test_10_persent( $calc_value, $orig_value, $persent, $message );
>
> #test if bigger or lower not lower then 10%
> sub test_10_persent {
>    my ( $calc_value, $orig_value, $persent, $message ) = @_;
>
>    if ( $calc_value >= $orig_value ) {
>        cmp_ok( $calc_value, '>=', $orig_value,
>            $message . " $calc_value >= $orig_value " );
>    }
>    else {
>        my $cal_persent =
>          floor( abs( ( ( $calc_value - $orig_value ) / $orig_value ) * 100
> ) );
>        cmp_ok( $cal_persent, '<=', $persent,
>            $message . " $calc_value <= $orig_value but not lower then 10 %"
> );
>    }
> }
>
>
> --
> Nikolay Mishin
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111026/a1554300/attachment.html>

From sergiy.borodych на gmail.com  Wed Oct 26 05:28:18 2011
From: sergiy.borodych на gmail.com (Sergiy Borodych)
Date: Wed, 26 Oct 2011 15:28:18 +0300
Subject: [Moscow.pm] Module::Loaded
In-Reply-To: <20111026070957.GE14585@apache.rbscorp.ru>
References: <20111026070957.GE14585@apache.rbscorp.ru>
Message-ID: <CAKckDDCuqcZjX549tpuBW+NwdV-saacrmrcRdzhgAEP-4sxa_Q@mail.gmail.com>

Hello,

2011/10/26 Ivan Petrov <i.petro.77.00 на gmail.com>:
> нужно написать некий функционал в стиле 'use base "Module"';
>
> соответственно хочется чтобы этот модуль делал 'require Module'.
>
> вроде все просто, однако хочется чтобы работало и с пакетами, которые
> не выделены в модули
>
> если пишем
>
> use Module::Loaded;
> use Module::Load;
>
> unless (loaded $module) {
>    load $module;
> }
>
> то load естественно обламывается в случае если передается имя пакета,
> который определен прямо в main::.
>

У меня работает.

#!/usr/bin/perl

use v5.10;
use strict;
use warnings;

use Module::Load;

load 'Test';
say 'OK';

package Test;
1;

> Понятно что можно поглядеть в пространство имен есть ли уже такой
> пакет или нет.
>
> но вот интересно, может стандартное есть что-то на эту тему чтобы
> велосипед не городить?

-- 
Sergiy Borodych
http://bor.org.ua

From chesnokov.ilya на gmail.com  Wed Oct 26 05:46:54 2011
From: chesnokov.ilya на gmail.com (Ilya Chesnokov)
Date: Wed, 26 Oct 2011 16:46:54 +0400
Subject: [Moscow.pm] Module::Loaded
In-Reply-To: <CAKckDDCuqcZjX549tpuBW+NwdV-saacrmrcRdzhgAEP-4sxa_Q@mail.gmail.com>
References: <20111026070957.GE14585@apache.rbscorp.ru>
	<CAKckDDCuqcZjX549tpuBW+NwdV-saacrmrcRdzhgAEP-4sxa_Q@mail.gmail.com>
Message-ID: <CANh0x-xv7P4J_Jth56uF_AJyKhsq7sr4ybW0Go4yEDn9hQgJFg@mail.gmail.com>

26 октября 2011 г. 16:28 пользователь Sergiy Borodych
<sergiy.borodych на gmail.com> написал:
> Hello,
>
> 2011/10/26 Ivan Petrov <i.petro.77.00 на gmail.com>:
>> нужно написать некий функционал в стиле 'use base "Module"';
>>
>> соответственно хочется чтобы этот модуль делал 'require Module'.
>>
>> вроде все просто, однако хочется чтобы работало и с пакетами, которые
>> не выделены в модули
>>
>> если пишем
>>
>> use Module::Loaded;
>> use Module::Load;
>>
>> unless (loaded $module) {
>>    load $module;
>> }
>>
>> то load естественно обламывается в случае если передается имя пакета,
>> который определен прямо в main::.
>>
>
> У меня работает.

)))
А вот такой скрипт что скажет?

#!/usr/bin/perl
use v5.10;
use strict;
use warnings;
use Module::Load;

load 'Test';
say $Test::VERSION;

package Test;

our $VERSION = 0.01;

1;


-- 
Best regards,
Ilya Chesnokov

From sergiy.borodych на gmail.com  Wed Oct 26 06:24:52 2011
From: sergiy.borodych на gmail.com (Sergiy Borodych)
Date: Wed, 26 Oct 2011 16:24:52 +0300
Subject: [Moscow.pm] Module::Loaded
In-Reply-To: <CANh0x-xv7P4J_Jth56uF_AJyKhsq7sr4ybW0Go4yEDn9hQgJFg@mail.gmail.com>
References: <20111026070957.GE14585@apache.rbscorp.ru>
	<CAKckDDCuqcZjX549tpuBW+NwdV-saacrmrcRdzhgAEP-4sxa_Q@mail.gmail.com>
	<CANh0x-xv7P4J_Jth56uF_AJyKhsq7sr4ybW0Go4yEDn9hQgJFg@mail.gmail.com>
Message-ID: <CAKckDDBEoq21QmYcaQ5Gdhzddh2tTAinyokTyqD+osvs8D7SXw@mail.gmail.com>

2011/10/26 Ilya Chesnokov <chesnokov.ilya на gmail.com>:
> 26 октября 2011 г. 16:28 пользователь Sergiy Borodych
> <sergiy.borodych на gmail.com> написал:
>> Hello,
>>
>> 2011/10/26 Ivan Petrov <i.petro.77.00 на gmail.com>:
>>> нужно написать некий функционал в стиле 'use base "Module"';
>>>
>>> соответственно хочется чтобы этот модуль делал 'require Module'.
>>>
>>> вроде все просто, однако хочется чтобы работало и с пакетами, которые
>>> не выделены в модули
>>>
>>> если пишем
>>>
>>> use Module::Loaded;
>>> use Module::Load;
>>>
>>> unless (loaded $module) {
>>>    load $module;
>>> }
>>>
>>> то load естественно обламывается в случае если передается имя пакета,
>>> который определен прямо в main::.
>>>
>>
>> У меня работает.
>
> )))
> А вот такой скрипт что скажет?
>
> #!/usr/bin/perl
> use v5.10;
> use strict;
> use warnings;
> use Module::Load;
>
> load 'Test';
> say $Test::VERSION;
>
> package Test;
>
> our $VERSION = 0.01;
>
> 1;
>

Эх, и хотел же написать "Странно, но ..." :)

-- 
Sergiy Borodych
http://bor.org.ua

From nikzubkov на gmail.com  Wed Oct 26 07:11:22 2011
From: nikzubkov на gmail.com (Nikita Zubkov)
Date: Wed, 26 Oct 2011 18:11:22 +0400
Subject: [Moscow.pm] Module::Loaded
In-Reply-To: <20111026070957.GE14585@apache.rbscorp.ru>
References: <20111026070957.GE14585@apache.rbscorp.ru>
Message-ID: <CAA4UdcQ-HtGKy77qGrx7QLOBcgP94pxOAGo3OwMAWpkJijy9TQ@mail.gmail.com>

А почему бы не делать как в base.pm?

                local $SIG{__DIE__};
                eval "require $base";
                # Only ignore "Can't locate" errors from our eval require.
                # Other fatal errors (syntax etc) must be reported.
                die if $@ && $@ !~ /^Can't locate .*? at \(eval /;

26 октября 2011 г. 11:09 пользователь Ivan Petrov
<i.petro.77.00 на gmail.com> написал:
> нужно написать некий функционал в стиле 'use base "Module"';
>
> соответственно хочется чтобы этот модуль делал 'require Module'.
>
> вроде все просто, однако хочется чтобы работало и с пакетами, которые
> не выделены в модули
>
> если пишем
>
> use Module::Loaded;
> use Module::Load;
>
> unless (loaded $module) {
>    load $module;
> }
>
> то load естественно обламывается в случае если передается имя пакета,
> который определен прямо в main::.
>
> Понятно что можно поглядеть в пространство имен есть ли уже такой
> пакет или нет.
>
> но вот интересно, может стандартное есть что-то на эту тему чтобы
> велосипед не городить?
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>

From peter на vereshagin.org  Wed Oct 26 07:17:24 2011
From: peter на vereshagin.org (Peter Vereshagin)
Date: Wed, 26 Oct 2011 18:17:24 +0400
Subject: [Moscow.pm]
 =?koi8-r?b?y8/NzcXO1NkgwdfUz9XLzMHE3snLz80g1yBwb2Q=?=
In-Reply-To: <60021319616108@web77.yandex.ru>
Message-ID: <20111026141724.GD5547@external.screwed.box>

Hello.

2011/10/26 02:19:08 -0700 moscow-pm-request на pm.org => To moscow-pm на pm.org :

> Супер идея, давно о таком мечтаю,
> мне кажется после __END__ в модуле самое то, вот еще бы
> сделать так, чтобы скрипт проходит по текущему скрипту и генерил такие поды на основе текущих функций, превращая комменты к функции
> #show current cursor from db
> sub say_values_from_db {
>     my $sth     = shift;#sql result
>     my $db_conn = shift;#connect to prod1.db
> ..
>    return \%values;#pure perl values from db
> }

my eyes! рекомендую пёрлтайди.

> в pod доку

и чтобы оно из этого какого вида бы тогда получалось?

> > понаделать  айтемы для пода:

на самом деле вот, например, Sub::Spec::To::Pod вроде ещё туда-сюда, но ему
входные данные надо будет представлять по-другому, это не самый удобный
вариант. Или даже вот:

	http://search.cpan.org/perldoc?Sub::Documentation::Attributes

но как-то хочется всё-таки из предсабовых комментов поды дёргать, не из чего-то
компилируемого.

--
Peter Vereshagin <peter на vereshagin.org> (http://vereshagin.org) pgp: A0E26627 

From i.petro.77.00 на gmail.com  Wed Oct 26 09:26:47 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Wed, 26 Oct 2011 20:26:47 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
Message-ID: <20111026162647.GF14585@apache.rbscorp.ru>

сделали мы тут цельный проект на DBIx::Class. С точки зрения
попробовать последний. До этого всегда использовали DBI, который
использовала модель в системе MVC.

Впечатления плохие, однако появились мысли куда надо двигаться чтобы
было хорошо. Я их тут изложу, а вы покритикуйте.

В первую очередь зачем как бы нужен был этот DBIC.
 - конструирование SQL-запросов
 - уход от смешивания кода Perl с кодом SQL
 - выборка объектов, а не хешей из БД, которые можно расширять своими
   методами
 - упрощение кода моделей с точки зрения что в простых случаях вообще
   не делать выделенную модель

Ничего не забыл?

По результатам проекта (проект был довольно большой и дальше еще будет
долго) я понял следующее:

1. даже в простых случаях DBIC на роль модели не годится. То есть в
любом случае нужно делать выделенную модель, пусть даже там один
resultset('Name')->find. Ибо тесты. При их написании мы применяем
способ "подменить модель на стадии тестирования".

2. DBIC не предоставляет хорошей абстракции над БД. Все равно
JOIN'ы, SELECT'ы торчат местами (например join_type => 'left' в has'ах
итп). То есть оперировать хранилищем как некоей абстракцией в реальном
случае не получается.

3. Конструктор SQL-запросов крайне страшен. Работали мы с постоянно
включенной отладкой (выводом всех делающихся запросов в лог). С одной
стороны есть множество вещей которые на DBIC сделать крайне непросто
(например многие аггрегаторные вещи), с другой стороны когда
начинается работа с более чем двумя таблицами он зачастую мутит такие
страшные вложенные SQL-запросы что волосы дыбом становятся, а с
третьей стороны использование фич конкретной БД становится затруднено.

В итоге пришли к тому, что в сложных случаях приходится делать в БД
view'ы только из за того что от DBIC добиться генерации нормального
запроса очень и очень сложно или невозможно. Набор опций при выборке
может быть больше самого SQL-запроса, если его просто написать.

Ну вот и в свете того, что код работы с DBIC все равно располагается в
моделях, конструировать эффективные SQL-запросы он все равно не умеет,
то из плюсов его использования остаются только:
 - выборка в объекты и итераторы по ним
 - уход от смешивания Perl и SQL

Соответственно размышляя над всем этим мы пришли к тому, что 

1. построить качественный автогенератор SQL запросов на все случаи
жизни (или по кр. мере на большинство) невозможно, поэтому его не
стоит и пытаться сделать

2. из за п.1 бОльшая часть DBIC становится не нужна, а надо делать
некоего помощника, который бы человеку просто помогал удобно работать
с БД.

то есть надо

1. написать свой итератор, работающий поверх массива или
хеша - выборки из БД.
2. написать базовую обертку над одной строкой выборки (доступ в виде
методов)
3. Используя 1 и 2 написать над DBI класс, который выборки блессает в
итераторы и объекты
4. решить вопрос с выносом SQL-кода из перловых модулей. То есть
обертка 3 должна уметь работать с SQL, располагающимися в файлах.


Вынос SQL в файлы очень плохо соотносится с дефолтными плейсхолдерами
DBI. поскольку они позиционные.

Вывод:
5. надо реализовывать именованные плейсхолдеры

ну и попутно 
5.1 реализовать плейсхолдерные (темплейтные) выражения для типовых
вещей, как-то
 INSERT ... VALUES (?,?,?),(?,?,?),(?,?,?),...

или
 SELECT ... WHERE id IN (?,?,?)

то есть подстановки массивов.

Соответственно исходя из этого родился набор модулей, который в
ближайшее время, если кому-то будет интересно, мы можем выложить на
CPAN (там еще работы на неск. дней осталось), который все это делает:

1. по дефолту блесает строки-выборки в объект, у которого три
предопределенных метода: new, is_changed, iterator. Плюс методы
совпадающие с именами выбранных столбиков.

2. блесает наборы-выборки в объект позволяющий делать проходы по
выборкам итп (совместимо с DBIC'шными ->all, while(...->next) итп

3. в п. 1 и 2 позволяет указывать свои классы для итераторов и выборок

4. позволяет вместо SQL использовать имена файлов SQL в предзаданной
директории (по аналогии с темлейтами любого вебпроекта)

5. реализует следующий набор подстановок в SQL

    ?{путь} - просто подставляет переменную
    ?@{путь} - подставляет массив переменных (через запятую)
    ?%{путь}{поле,поле,...} - подставляет массив переменных (через
          запятую) из массива хешей
    
    ну и на вс случай сделали
    ?sub{перловый код}


    А так же набор условных подстановок вроде

    ?if[de]?{путь}{ блок который вставится }{else-блок}

    условия - if - истина
              ifd - определен
              ife - имеется

   Блоки можно вкладывать друг в друга.

   пути - по сути путь к переменной во входном хеше, то есть

   $dbh->do($sql, values => { ids => [1, 3, 5] }, abc => 'def');

   путями являются
   'values'
   'abc'
   'values.ids'

   и так далее.

   поддерживаются в путях и объекты

   path.to:method  - будет вызван метод объекта, а значение им
   возвращенное будет вставлено в SQL.


В итоге что получили:

1. SQL вынесен в отдельный каталог (отдельные каталоги) примерно так
же как вынесены темплейты в любом вебпроекте
2. типичные SQL-вещи делаются просто. Сложные тоже можно делать.
3. Поскольку итератор по именам методов постарались сделать
совместимым с DBIC то замена одного на другое не вызывает больших
трудностей.

ну и возьмем пример:

скажем приходит от пользователя форма

$filters = { region => 'Москва', street => '' };

То есть он фильтр по региону заполнил, а фильтр по улице нет

запрос может выглядеть так

SELECT
    *
FROM
    tbl1
LEFT JOIN tbl2 ...

WHERE
    something = ..

    ?if{filters.region}{ AND region = ?{filters.region} }
    ?if{filters.street}{ AND street = ?{filters.street} }

и так далее.

Получается SQL перестраивается в зависимости от того что там вводит
пользователь. 

Осталось нерешенными некоторые типовые вопросы, но мы их планируем
порешать в ближайшее время (например подставновки частей в
like-секции)

соответственно вопросы:

1. кому-нибудь интересна подобная система, стоит класть на CPAN?
2. может на эту тему есть что-то готовое да мы велик очередной ваяем?
тогда ткните указкой:)

From andrei.protasovitski на gmail.com  Wed Oct 26 09:47:06 2011
From: andrei.protasovitski на gmail.com (Andrei)
Date: Wed, 26 Oct 2011 18:47:06 +0200
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111026162647.GF14585@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
Message-ID: <CANVWn7EEjv7_OGN8FmXGb7hruq_R9LW+1iuOFPwNP7bNugKcuQ@mail.gmail.com>

И как у этого велосипеда с производительностью на больших объёмах данных?

26 октября 2011 г. 18:26 пользователь Ivan Petrov
<i.petro.77.00 на gmail.com>написал:

> сделали мы тут цельный проект на DBIx::Class. С точки зрения
> попробовать последний. До этого всегда использовали DBI, который
> использовала модель в системе MVC.
>
> Впечатления плохие, однако появились мысли куда надо двигаться чтобы
> было хорошо. Я их тут изложу, а вы покритикуйте.
>
> В первую очередь зачем как бы нужен был этот DBIC.
>  - конструирование SQL-запросов
>  - уход от смешивания кода Perl с кодом SQL
>  - выборка объектов, а не хешей из БД, которые можно расширять своими
>   методами
>  - упрощение кода моделей с точки зрения что в простых случаях вообще
>   не делать выделенную модель
>
> Ничего не забыл?
>
> По результатам проекта (проект был довольно большой и дальше еще будет
> долго) я понял следующее:
>
> 1. даже в простых случаях DBIC на роль модели не годится. То есть в
> любом случае нужно делать выделенную модель, пусть даже там один
> resultset('Name')->find. Ибо тесты. При их написании мы применяем
> способ "подменить модель на стадии тестирования".
>
> 2. DBIC не предоставляет хорошей абстракции над БД. Все равно
> JOIN'ы, SELECT'ы торчат местами (например join_type => 'left' в has'ах
> итп). То есть оперировать хранилищем как некоей абстракцией в реальном
> случае не получается.
>
> 3. Конструктор SQL-запросов крайне страшен. Работали мы с постоянно
> включенной отладкой (выводом всех делающихся запросов в лог). С одной
> стороны есть множество вещей которые на DBIC сделать крайне непросто
> (например многие аггрегаторные вещи), с другой стороны когда
> начинается работа с более чем двумя таблицами он зачастую мутит такие
> страшные вложенные SQL-запросы что волосы дыбом становятся, а с
> третьей стороны использование фич конкретной БД становится затруднено.
>
> В итоге пришли к тому, что в сложных случаях приходится делать в БД
> view'ы только из за того что от DBIC добиться генерации нормального
> запроса очень и очень сложно или невозможно. Набор опций при выборке
> может быть больше самого SQL-запроса, если его просто написать.
>
> Ну вот и в свете того, что код работы с DBIC все равно располагается в
> моделях, конструировать эффективные SQL-запросы он все равно не умеет,
> то из плюсов его использования остаются только:
>  - выборка в объекты и итераторы по ним
>  - уход от смешивания Perl и SQL
>
> Соответственно размышляя над всем этим мы пришли к тому, что
>
> 1. построить качественный автогенератор SQL запросов на все случаи
> жизни (или по кр. мере на большинство) невозможно, поэтому его не
> стоит и пытаться сделать
>
> 2. из за п.1 бОльшая часть DBIC становится не нужна, а надо делать
> некоего помощника, который бы человеку просто помогал удобно работать
> с БД.
>
> то есть надо
>
> 1. написать свой итератор, работающий поверх массива или
> хеша - выборки из БД.
> 2. написать базовую обертку над одной строкой выборки (доступ в виде
> методов)
> 3. Используя 1 и 2 написать над DBI класс, который выборки блессает в
> итераторы и объекты
> 4. решить вопрос с выносом SQL-кода из перловых модулей. То есть
> обертка 3 должна уметь работать с SQL, располагающимися в файлах.
>
>
> Вынос SQL в файлы очень плохо соотносится с дефолтными плейсхолдерами
> DBI. поскольку они позиционные.
>
> Вывод:
> 5. надо реализовывать именованные плейсхолдеры
>
> ну и попутно
> 5.1 реализовать плейсхолдерные (темплейтные) выражения для типовых
> вещей, как-то
>  INSERT ... VALUES (?,?,?),(?,?,?),(?,?,?),...
>
> или
>  SELECT ... WHERE id IN (?,?,?)
>
> то есть подстановки массивов.
>
> Соответственно исходя из этого родился набор модулей, который в
> ближайшее время, если кому-то будет интересно, мы можем выложить на
> CPAN (там еще работы на неск. дней осталось), который все это делает:
>
> 1. по дефолту блесает строки-выборки в объект, у которого три
> предопределенных метода: new, is_changed, iterator. Плюс методы
> совпадающие с именами выбранных столбиков.
>
> 2. блесает наборы-выборки в объект позволяющий делать проходы по
> выборкам итп (совместимо с DBIC'шными ->all, while(...->next) итп
>
> 3. в п. 1 и 2 позволяет указывать свои классы для итераторов и выборок
>
> 4. позволяет вместо SQL использовать имена файлов SQL в предзаданной
> директории (по аналогии с темлейтами любого вебпроекта)
>
> 5. реализует следующий набор подстановок в SQL
>
>    ?{путь} - просто подставляет переменную
>    ?@{путь} - подставляет массив переменных (через запятую)
>    ?%{путь}{поле,поле,...} - подставляет массив переменных (через
>          запятую) из массива хешей
>
>    ну и на вс случай сделали
>    ?sub{перловый код}
>
>
>    А так же набор условных подстановок вроде
>
>    ?if[de]?{путь}{ блок который вставится }{else-блок}
>
>    условия - if - истина
>              ifd - определен
>              ife - имеется
>
>   Блоки можно вкладывать друг в друга.
>
>   пути - по сути путь к переменной во входном хеше, то есть
>
>   $dbh->do($sql, values => { ids => [1, 3, 5] }, abc => 'def');
>
>   путями являются
>   'values'
>   'abc'
>   'values.ids'
>
>   и так далее.
>
>   поддерживаются в путях и объекты
>
>   path.to:method  - будет вызван метод объекта, а значение им
>   возвращенное будет вставлено в SQL.
>
>
> В итоге что получили:
>
> 1. SQL вынесен в отдельный каталог (отдельные каталоги) примерно так
> же как вынесены темплейты в любом вебпроекте
> 2. типичные SQL-вещи делаются просто. Сложные тоже можно делать.
> 3. Поскольку итератор по именам методов постарались сделать
> совместимым с DBIC то замена одного на другое не вызывает больших
> трудностей.
>
> ну и возьмем пример:
>
> скажем приходит от пользователя форма
>
> $filters = { region => 'Москва', street => '' };
>
> То есть он фильтр по региону заполнил, а фильтр по улице нет
>
> запрос может выглядеть так
>
> SELECT
>    *
> FROM
>    tbl1
> LEFT JOIN tbl2 ...
>
> WHERE
>    something = ..
>
>    ?if{filters.region}{ AND region = ?{filters.region} }
>    ?if{filters.street}{ AND street = ?{filters.street} }
>
> и так далее.
>
> Получается SQL перестраивается в зависимости от того что там вводит
> пользователь.
>
> Осталось нерешенными некоторые типовые вопросы, но мы их планируем
> порешать в ближайшее время (например подставновки частей в
> like-секции)
>
> соответственно вопросы:
>
> 1. кому-нибудь интересна подобная система, стоит класть на CPAN?
> 2. может на эту тему есть что-то готовое да мы велик очередной ваяем?
> тогда ткните указкой:)
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
Andrei Protasovitski
< andrei[dot]protasovitski[at]gmail[dot]com >
Diemen, Netherlands
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111026/3e357a7c/attachment-0001.html>

From i.petro.77.00 на gmail.com  Wed Oct 26 09:53:18 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Wed, 26 Oct 2011 20:53:18 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <CANVWn7EEjv7_OGN8FmXGb7hruq_R9LW+1iuOFPwNP7bNugKcuQ@mail.gmail.com>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<CANVWn7EEjv7_OGN8FmXGb7hruq_R9LW+1iuOFPwNP7bNugKcuQ@mail.gmail.com>
Message-ID: <20111026165318.GG14585@apache.rbscorp.ru>

> И как у этого велосипеда с производительностью на больших объёмах данных?

Сильно лучше чем у DBIC. Запросы человек пишет много качественнее
DBIC. Даже тупой человек.

ну а по сравнению с чистым DBI оверхед относительно небольшой:
поскольку синтаксис "велосипеда" несложный, то там относительно
простыми регулярками замены делаются.


From shafiev на gmail.com  Wed Oct 26 10:03:01 2011
From: shafiev на gmail.com (Naim Shafiev)
Date: Wed, 26 Oct 2011 22:03:01 +0500
Subject: [Moscow.pm]
	=?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
	=?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <20111026162647.GF14585@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
Message-ID: <CAGYhLe1p=EU71FmjvbN+a_ozQVC3DqdehpvqAp_Tce5VmEceJg@mail.gmail.com>

26 октября 2011 г. 21:26 пользователь Ivan Petrov
<i.petro.77.00 на gmail.com> написал:
> сделали мы тут цельный проект на DBIx::Class. С точки зрения
> попробовать последний. До этого всегда использовали DBI, который
> использовала модель в системе MVC.
>
> Впечатления плохие, однако появились мысли куда надо двигаться чтобы
> было хорошо. Я их тут изложу, а вы покритикуйте.
>
> В первую очередь зачем как бы нужен был этот DBIC.
>  - конструирование SQL-запросов
>  - уход от смешивания кода Perl с кодом SQL
>  - выборка объектов, а не хешей из БД, которые можно расширять своими
>   методами
>  - упрощение кода моделей с точки зрения что в простых случаях вообще
>   не делать выделенную модель
>
> Ничего не забыл?
>
> По результатам проекта (проект был довольно большой и дальше еще будет
> долго) я понял следующее:
>
> 1. даже в простых случаях DBIC на роль модели не годится. То есть в
> любом случае нужно делать выделенную модель, пусть даже там один
> resultset('Name')->find. Ибо тесты. При их написании мы применяем
> способ "подменить модель на стадии тестирования".
>
> 2. DBIC не предоставляет хорошей абстракции над БД. Все равно
> JOIN'ы, SELECT'ы торчат местами (например join_type => 'left' в has'ах
> итп). То есть оперировать хранилищем как некоей абстракцией в реальном
> случае не получается.
>
> 3. Конструктор SQL-запросов крайне страшен. Работали мы с постоянно
> включенной отладкой (выводом всех делающихся запросов в лог). С одной
> стороны есть множество вещей которые на DBIC сделать крайне непросто
> (например многие аггрегаторные вещи), с другой стороны когда
> начинается работа с более чем двумя таблицами он зачастую мутит такие
> страшные вложенные SQL-запросы что волосы дыбом становятся, а с
> третьей стороны использование фич конкретной БД становится затруднено.
>
> В итоге пришли к тому, что в сложных случаях приходится делать в БД
> view'ы только из за того что от DBIC добиться генерации нормального
> запроса очень и очень сложно или невозможно. Набор опций при выборке
> может быть больше самого SQL-запроса, если его просто написать.
>
> Ну вот и в свете того, что код работы с DBIC все равно располагается в
> моделях, конструировать эффективные SQL-запросы он все равно не умеет,
> то из плюсов его использования остаются только:
>  - выборка в объекты и итераторы по ним
>  - уход от смешивания Perl и SQL
>
> Соответственно размышляя над всем этим мы пришли к тому, что
>
> 1. построить качественный автогенератор SQL запросов на все случаи
> жизни (или по кр. мере на большинство) невозможно, поэтому его не
> стоит и пытаться сделать
>
> 2. из за п.1 бОльшая часть DBIC становится не нужна, а надо делать
> некоего помощника, который бы человеку просто помогал удобно работать
> с БД.
>
> то есть надо
>
> 1. написать свой итератор, работающий поверх массива или
> хеша - выборки из БД.
> 2. написать базовую обертку над одной строкой выборки (доступ в виде
> методов)
> 3. Используя 1 и 2 написать над DBI класс, который выборки блессает в
> итераторы и объекты
> 4. решить вопрос с выносом SQL-кода из перловых модулей. То есть
> обертка 3 должна уметь работать с SQL, располагающимися в файлах.
>
>
> Вынос SQL в файлы очень плохо соотносится с дефолтными плейсхолдерами
> DBI. поскольку они позиционные.
>
> Вывод:
> 5. надо реализовывать именованные плейсхолдеры
>
> ну и попутно
> 5.1 реализовать плейсхолдерные (темплейтные) выражения для типовых
> вещей, как-то
>  INSERT ... VALUES (?,?,?),(?,?,?),(?,?,?),...
>
> или
>  SELECT ... WHERE id IN (?,?,?)
>
> то есть подстановки массивов.
>
> Соответственно исходя из этого родился набор модулей, который в
> ближайшее время, если кому-то будет интересно, мы можем выложить на
> CPAN (там еще работы на неск. дней осталось), который все это делает:
>
> 1. по дефолту блесает строки-выборки в объект, у которого три
> предопределенных метода: new, is_changed, iterator. Плюс методы
> совпадающие с именами выбранных столбиков.
>
> 2. блесает наборы-выборки в объект позволяющий делать проходы по
> выборкам итп (совместимо с DBIC'шными ->all, while(...->next) итп
>
> 3. в п. 1 и 2 позволяет указывать свои классы для итераторов и выборок
>
> 4. позволяет вместо SQL использовать имена файлов SQL в предзаданной
> директории (по аналогии с темлейтами любого вебпроекта)
>
> 5. реализует следующий набор подстановок в SQL
>
>    ?{путь} - просто подставляет переменную
>    ?@{путь} - подставляет массив переменных (через запятую)
>    ?%{путь}{поле,поле,...} - подставляет массив переменных (через
>          запятую) из массива хешей
>
>    ну и на вс случай сделали
>    ?sub{перловый код}
>
>
>    А так же набор условных подстановок вроде
>
>    ?if[de]?{путь}{ блок который вставится }{else-блок}
>
>    условия - if - истина
>              ifd - определен
>              ife - имеется
>
>   Блоки можно вкладывать друг в друга.
>
>   пути - по сути путь к переменной во входном хеше, то есть
>
>   $dbh->do($sql, values => { ids => [1, 3, 5] }, abc => 'def');
>
>   путями являются
>   'values'
>   'abc'
>   'values.ids'
>
>   и так далее.
>
>   поддерживаются в путях и объекты
>
>   path.to:method  - будет вызван метод объекта, а значение им
>   возвращенное будет вставлено в SQL.
>
>
> В итоге что получили:
>
> 1. SQL вынесен в отдельный каталог (отдельные каталоги) примерно так
> же как вынесены темплейты в любом вебпроекте
> 2. типичные SQL-вещи делаются просто. Сложные тоже можно делать.
> 3. Поскольку итератор по именам методов постарались сделать
> совместимым с DBIC то замена одного на другое не вызывает больших
> трудностей.
>
> ну и возьмем пример:
>
> скажем приходит от пользователя форма
>
> $filters = { region => 'Москва', street => '' };
>
> То есть он фильтр по региону заполнил, а фильтр по улице нет
>
> запрос может выглядеть так
>
> SELECT
>    *
> FROM
>    tbl1
> LEFT JOIN tbl2 ...
>
> WHERE
>    something = ..
>
>    ?if{filters.region}{ AND region = ?{filters.region} }
>    ?if{filters.street}{ AND street = ?{filters.street} }
>
> и так далее.
>
> Получается SQL перестраивается в зависимости от того что там вводит
> пользователь.
>
> Осталось нерешенными некоторые типовые вопросы, но мы их планируем
> порешать в ближайшее время (например подставновки частей в
> like-секции)
>
> соответственно вопросы:
>
> 1. кому-нибудь интересна подобная система, стоит класть на CPAN?

Безусловно стоит.При множестве глаз баги выплывают  на поверхность

> 2. может на эту тему есть что-то готовое да мы велик очередной ваяем?
> тогда ткните указкой:)
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>

From andrey на kostenko.name  Wed Oct 26 10:09:04 2011
From: andrey на kostenko.name (Andrii Kostenko)
Date: Wed, 26 Oct 2011 21:09:04 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <20111026162647.GF14585@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
Message-ID: <0BF3245D-1EAF-4B92-B002-6EF6EE15F81D@kostenko.name>

Вы готовите его неправильно

1. Нужно подменять storage, а не модель.
2. Если правильно выбирать has_one/belongs_to, то join_type => 'left' нужен в исключительных случаях
3. К сожалению, да. DBIx::Class работает хорошо только с хорошей структурой БД. Когда все просто и не нужно делать SQL-извращений для получения результата.


On 26.10.2011, at 20:26, Ivan Petrov wrote:

> сделали мы тут цельный проект на DBIx::Class. С точки зрения
> попробовать последний. До этого всегда использовали DBI, который
> использовала модель в системе MVC.
> 
> Впечатления плохие, однако появились мысли куда надо двигаться чтобы
> было хорошо. Я их тут изложу, а вы покритикуйте.
> 
> В первую очередь зачем как бы нужен был этот DBIC.
> - конструирование SQL-запросов
> - уход от смешивания кода Perl с кодом SQL
> - выборка объектов, а не хешей из БД, которые можно расширять своими
>   методами
> - упрощение кода моделей с точки зрения что в простых случаях вообще
>   не делать выделенную модель
> 
> Ничего не забыл?
> 
> По результатам проекта (проект был довольно большой и дальше еще будет
> долго) я понял следующее:
> 
> 1. даже в простых случаях DBIC на роль модели не годится. То есть в
> любом случае нужно делать выделенную модель, пусть даже там один
> resultset('Name')->find. Ибо тесты. При их написании мы применяем
> способ "подменить модель на стадии тестирования".
> 
> 2. DBIC не предоставляет хорошей абстракции над БД. Все равно
> JOIN'ы, SELECT'ы торчат местами (например join_type => 'left' в has'ах
> итп). То есть оперировать хранилищем как некоей абстракцией в реальном
> случае не получается.
> 
> 3. Конструктор SQL-запросов крайне страшен. Работали мы с постоянно
> включенной отладкой (выводом всех делающихся запросов в лог). С одной
> стороны есть множество вещей которые на DBIC сделать крайне непросто
> (например многие аггрегаторные вещи), с другой стороны когда
> начинается работа с более чем двумя таблицами он зачастую мутит такие
> страшные вложенные SQL-запросы что волосы дыбом становятся, а с
> третьей стороны использование фич конкретной БД становится затруднено.
> 
> В итоге пришли к тому, что в сложных случаях приходится делать в БД
> view'ы только из за того что от DBIC добиться генерации нормального
> запроса очень и очень сложно или невозможно. Набор опций при выборке
> может быть больше самого SQL-запроса, если его просто написать.
> 
> Ну вот и в свете того, что код работы с DBIC все равно располагается в
> моделях, конструировать эффективные SQL-запросы он все равно не умеет,
> то из плюсов его использования остаются только:
> - выборка в объекты и итераторы по ним
> - уход от смешивания Perl и SQL
> 
> Соответственно размышляя над всем этим мы пришли к тому, что 
> 
> 1. построить качественный автогенератор SQL запросов на все случаи
> жизни (или по кр. мере на большинство) невозможно, поэтому его не
> стоит и пытаться сделать
> 
> 2. из за п.1 бОльшая часть DBIC становится не нужна, а надо делать
> некоего помощника, который бы человеку просто помогал удобно работать
> с БД.
> 
> то есть надо
> 
> 1. написать свой итератор, работающий поверх массива или
> хеша - выборки из БД.
> 2. написать базовую обертку над одной строкой выборки (доступ в виде
> методов)
> 3. Используя 1 и 2 написать над DBI класс, который выборки блессает в
> итераторы и объекты
> 4. решить вопрос с выносом SQL-кода из перловых модулей. То есть
> обертка 3 должна уметь работать с SQL, располагающимися в файлах.
> 
> 
> Вынос SQL в файлы очень плохо соотносится с дефолтными плейсхолдерами
> DBI. поскольку они позиционные.
> 
> Вывод:
> 5. надо реализовывать именованные плейсхолдеры
> 
> ну и попутно 
> 5.1 реализовать плейсхолдерные (темплейтные) выражения для типовых
> вещей, как-то
> INSERT ... VALUES (?,?,?),(?,?,?),(?,?,?),...
> 
> или
> SELECT ... WHERE id IN (?,?,?)
> 
> то есть подстановки массивов.
> 
> Соответственно исходя из этого родился набор модулей, который в
> ближайшее время, если кому-то будет интересно, мы можем выложить на
> CPAN (там еще работы на неск. дней осталось), который все это делает:
> 
> 1. по дефолту блесает строки-выборки в объект, у которого три
> предопределенных метода: new, is_changed, iterator. Плюс методы
> совпадающие с именами выбранных столбиков.
> 
> 2. блесает наборы-выборки в объект позволяющий делать проходы по
> выборкам итп (совместимо с DBIC'шными ->all, while(...->next) итп
> 
> 3. в п. 1 и 2 позволяет указывать свои классы для итераторов и выборок
> 
> 4. позволяет вместо SQL использовать имена файлов SQL в предзаданной
> директории (по аналогии с темлейтами любого вебпроекта)
> 
> 5. реализует следующий набор подстановок в SQL
> 
>    ?{путь} - просто подставляет переменную
>    ?@{путь} - подставляет массив переменных (через запятую)
>    ?%{путь}{поле,поле,...} - подставляет массив переменных (через
>          запятую) из массива хешей
> 
>    ну и на вс случай сделали
>    ?sub{перловый код}
> 
> 
>    А так же набор условных подстановок вроде
> 
>    ?if[de]?{путь}{ блок который вставится }{else-блок}
> 
>    условия - if - истина
>              ifd - определен
>              ife - имеется
> 
>   Блоки можно вкладывать друг в друга.
> 
>   пути - по сути путь к переменной во входном хеше, то есть
> 
>   $dbh->do($sql, values => { ids => [1, 3, 5] }, abc => 'def');
> 
>   путями являются
>   'values'
>   'abc'
>   'values.ids'
> 
>   и так далее.
> 
>   поддерживаются в путях и объекты
> 
>   path.to:method  - будет вызван метод объекта, а значение им
>   возвращенное будет вставлено в SQL.
> 
> 
> В итоге что получили:
> 
> 1. SQL вынесен в отдельный каталог (отдельные каталоги) примерно так
> же как вынесены темплейты в любом вебпроекте
> 2. типичные SQL-вещи делаются просто. Сложные тоже можно делать.
> 3. Поскольку итератор по именам методов постарались сделать
> совместимым с DBIC то замена одного на другое не вызывает больших
> трудностей.
> 
> ну и возьмем пример:
> 
> скажем приходит от пользователя форма
> 
> $filters = { region => 'Москва', street => '' };
> 
> То есть он фильтр по региону заполнил, а фильтр по улице нет
> 
> запрос может выглядеть так
> 
> SELECT
>    *
> FROM
>    tbl1
> LEFT JOIN tbl2 ...
> 
> WHERE
>    something = ..
> 
>    ?if{filters.region}{ AND region = ?{filters.region} }
>    ?if{filters.street}{ AND street = ?{filters.street} }
> 
> и так далее.
> 
> Получается SQL перестраивается в зависимости от того что там вводит
> пользователь. 
> 
> Осталось нерешенными некоторые типовые вопросы, но мы их планируем
> порешать в ближайшее время (например подставновки частей в
> like-секции)
> 
> соответственно вопросы:
> 
> 1. кому-нибудь интересна подобная система, стоит класть на CPAN?
> 2. может на эту тему есть что-то готовое да мы велик очередной ваяем?
> тогда ткните указкой:)
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org


From yu.pats на gmail.com  Wed Oct 26 10:13:49 2011
From: yu.pats на gmail.com (Yury Pats)
Date: Wed, 26 Oct 2011 20:13:49 +0300
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <CANVWn7EEjv7_OGN8FmXGb7hruq_R9LW+1iuOFPwNP7bNugKcuQ@mail.gmail.com>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<CANVWn7EEjv7_OGN8FmXGb7hruq_R9LW+1iuOFPwNP7bNugKcuQ@mail.gmail.com>
Message-ID: <CAFtO3fn13sErnp6cdLHvynczdL6Osx+m82BjucTu+P4Y1Laj4w@mail.gmail.com>

2011/10/26 Andrei <andrei.protasovitski на gmail.com>:
> И как у этого велосипеда с производительностью на больших объёмах данных?
>
Расскажи лучше нам про велосипед из патченного CDBI :)

Но вопрос задан правильно. Универсальное решение не будет шустро
работать при полноценном использовании его универсальности.


>> соответственно вопросы:
>>
>> 1. кому-нибудь интересна подобная система, стоит класть на CPAN?
Выкладывайте хотя бы на гитхаб!


> 26 октября 2011 г. 18:26 пользователь Ivan Petrov <i.petro.77.00 на gmail.com>
> написал:
>>
>> сделали мы тут цельный проект на DBIx::Class. С точки зрения
>> попробовать последний. До этого всегда использовали DBI, который
>> использовала модель в системе MVC.
>>
>> Впечатления плохие, однако появились мысли куда надо двигаться чтобы
>> было хорошо. Я их тут изложу, а вы покритикуйте.
>>
>> В первую очередь зачем как бы нужен был этот DBIC.
>>  - конструирование SQL-запросов
>>  - уход от смешивания кода Perl с кодом SQL
>>  - выборка объектов, а не хешей из БД, которые можно расширять своими
>>   методами
>>  - упрощение кода моделей с точки зрения что в простых случаях вообще
>>   не делать выделенную модель
>>
>> Ничего не забыл?
>>
>> По результатам проекта (проект был довольно большой и дальше еще будет
>> долго) я понял следующее:
>>
>> 1. даже в простых случаях DBIC на роль модели не годится. То есть в
>> любом случае нужно делать выделенную модель, пусть даже там один
>> resultset('Name')->find. Ибо тесты. При их написании мы применяем
>> способ "подменить модель на стадии тестирования".
>>
>> 2. DBIC не предоставляет хорошей абстракции над БД. Все равно
>> JOIN'ы, SELECT'ы торчат местами (например join_type => 'left' в has'ах
>> итп). То есть оперировать хранилищем как некоей абстракцией в реальном
>> случае не получается.
>>
>> 3. Конструктор SQL-запросов крайне страшен. Работали мы с постоянно
>> включенной отладкой (выводом всех делающихся запросов в лог). С одной
>> стороны есть множество вещей которые на DBIC сделать крайне непросто
>> (например многие аггрегаторные вещи), с другой стороны когда
>> начинается работа с более чем двумя таблицами он зачастую мутит такие
>> страшные вложенные SQL-запросы что волосы дыбом становятся, а с
>> третьей стороны использование фич конкретной БД становится затруднено.
>>
>> В итоге пришли к тому, что в сложных случаях приходится делать в БД
>> view'ы только из за того что от DBIC добиться генерации нормального
>> запроса очень и очень сложно или невозможно. Набор опций при выборке
>> может быть больше самого SQL-запроса, если его просто написать.
>>
>> Ну вот и в свете того, что код работы с DBIC все равно располагается в
>> моделях, конструировать эффективные SQL-запросы он все равно не умеет,
>> то из плюсов его использования остаются только:
>>  - выборка в объекты и итераторы по ним
>>  - уход от смешивания Perl и SQL
>>
>> Соответственно размышляя над всем этим мы пришли к тому, что
>>
>> 1. построить качественный автогенератор SQL запросов на все случаи
>> жизни (или по кр. мере на большинство) невозможно, поэтому его не
>> стоит и пытаться сделать
>>
>> 2. из за п.1 бОльшая часть DBIC становится не нужна, а надо делать
>> некоего помощника, который бы человеку просто помогал удобно работать
>> с БД.
>>
>> то есть надо
>>
>> 1. написать свой итератор, работающий поверх массива или
>> хеша - выборки из БД.
>> 2. написать базовую обертку над одной строкой выборки (доступ в виде
>> методов)
>> 3. Используя 1 и 2 написать над DBI класс, который выборки блессает в
>> итераторы и объекты
>> 4. решить вопрос с выносом SQL-кода из перловых модулей. То есть
>> обертка 3 должна уметь работать с SQL, располагающимися в файлах.
>>
>>
>> Вынос SQL в файлы очень плохо соотносится с дефолтными плейсхолдерами
>> DBI. поскольку они позиционные.
>>
>> Вывод:
>> 5. надо реализовывать именованные плейсхолдеры
>>
>> ну и попутно
>> 5.1 реализовать плейсхолдерные (темплейтные) выражения для типовых
>> вещей, как-то
>>  INSERT ... VALUES (?,?,?),(?,?,?),(?,?,?),...
>>
>> или
>>  SELECT ... WHERE id IN (?,?,?)
>>
>> то есть подстановки массивов.
>>
>> Соответственно исходя из этого родился набор модулей, который в
>> ближайшее время, если кому-то будет интересно, мы можем выложить на
>> CPAN (там еще работы на неск. дней осталось), который все это делает:
>>
>> 1. по дефолту блесает строки-выборки в объект, у которого три
>> предопределенных метода: new, is_changed, iterator. Плюс методы
>> совпадающие с именами выбранных столбиков.
>>
>> 2. блесает наборы-выборки в объект позволяющий делать проходы по
>> выборкам итп (совместимо с DBIC'шными ->all, while(...->next) итп
>>
>> 3. в п. 1 и 2 позволяет указывать свои классы для итераторов и выборок
>>
>> 4. позволяет вместо SQL использовать имена файлов SQL в предзаданной
>> директории (по аналогии с темлейтами любого вебпроекта)
>>
>> 5. реализует следующий набор подстановок в SQL
>>
>>    ?{путь} - просто подставляет переменную
>>    ?@{путь} - подставляет массив переменных (через запятую)
>>    ?%{путь}{поле,поле,...} - подставляет массив переменных (через
>>          запятую) из массива хешей
>>
>>    ну и на вс случай сделали
>>    ?sub{перловый код}
>>
>>
>>    А так же набор условных подстановок вроде
>>
>>    ?if[de]?{путь}{ блок который вставится }{else-блок}
>>
>>    условия - if - истина
>>              ifd - определен
>>              ife - имеется
>>
>>   Блоки можно вкладывать друг в друга.
>>
>>   пути - по сути путь к переменной во входном хеше, то есть
>>
>>   $dbh->do($sql, values => { ids => [1, 3, 5] }, abc => 'def');
>>
>>   путями являются
>>   'values'
>>   'abc'
>>   'values.ids'
>>
>>   и так далее.
>>
>>   поддерживаются в путях и объекты
>>
>>   path.to:method  - будет вызван метод объекта, а значение им
>>   возвращенное будет вставлено в SQL.
>>
>>
>> В итоге что получили:
>>
>> 1. SQL вынесен в отдельный каталог (отдельные каталоги) примерно так
>> же как вынесены темплейты в любом вебпроекте
>> 2. типичные SQL-вещи делаются просто. Сложные тоже можно делать.
>> 3. Поскольку итератор по именам методов постарались сделать
>> совместимым с DBIC то замена одного на другое не вызывает больших
>> трудностей.
>>
>> ну и возьмем пример:
>>
>> скажем приходит от пользователя форма
>>
>> $filters = { region => 'Москва', street => '' };
>>
>> То есть он фильтр по региону заполнил, а фильтр по улице нет
>>
>> запрос может выглядеть так
>>
>> SELECT
>>    *
>> FROM
>>    tbl1
>> LEFT JOIN tbl2 ...
>>
>> WHERE
>>    something = ..
>>
>>    ?if{filters.region}{ AND region = ?{filters.region} }
>>    ?if{filters.street}{ AND street = ?{filters.street} }
>>
>> и так далее.
>>
>> Получается SQL перестраивается в зависимости от того что там вводит
>> пользователь.
>>
>> Осталось нерешенными некоторые типовые вопросы, но мы их планируем
>> порешать в ближайшее время (например подставновки частей в
>> like-секции)
>>
>> соответственно вопросы:
>>
>> 1. кому-нибудь интересна подобная система, стоит класть на CPAN?
>> 2. может на эту тему есть что-то готовое да мы велик очередной ваяем?
>> тогда ткните указкой:)
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>
>
>
> --
> Andrei Protasovitski
> < andrei[dot]protasovitski[at]gmail[dot]com >
> Diemen, Netherlands
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>



-- 
WBR, Yury Pats
skype: yuripats
cellular: +375 (29) 5870723

From andrei.protasovitski на gmail.com  Wed Oct 26 10:15:58 2011
From: andrei.protasovitski на gmail.com (Andrei)
Date: Wed, 26 Oct 2011 19:15:58 +0200
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111026165318.GG14585@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<CANVWn7EEjv7_OGN8FmXGb7hruq_R9LW+1iuOFPwNP7bNugKcuQ@mail.gmail.com>
	<20111026165318.GG14585@apache.rbscorp.ru>
Message-ID: <CANVWn7Ey6nHo2P5_hpd3Vb6123pRrN4jrp3mR+HqmCW+nmspDw@mail.gmail.com>

А можно данные каких-нибудь тестов привести в доказательство этого тезиса? А
то у меня очень сильное чувство, что этот велосипед работает только в этом
проекте и ни разу не универсален.

26 октября 2011 г. 18:53 пользователь Ivan Petrov
<i.petro.77.00 на gmail.com>написал:

> > И как у этого велосипеда с производительностью на больших объёмах данных?
>
> Сильно лучше чем у DBIC. Запросы человек пишет много качественнее
> DBIC. Даже тупой человек.
>
> ну а по сравнению с чистым DBI оверхед относительно небольшой:
> поскольку синтаксис "велосипеда" несложный, то там относительно
> простыми регулярками замены делаются.
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
Andrei Protasovitski
< andrei[dot]protasovitski[at]gmail[dot]com >
Diemen, Netherlands
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111026/586a7ab7/attachment.html>

From yu.pats на gmail.com  Wed Oct 26 10:15:55 2011
From: yu.pats на gmail.com (Yury Pats)
Date: Wed, 26 Oct 2011 20:15:55 +0300
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111026165318.GG14585@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<CANVWn7EEjv7_OGN8FmXGb7hruq_R9LW+1iuOFPwNP7bNugKcuQ@mail.gmail.com>
	<20111026165318.GG14585@apache.rbscorp.ru>
Message-ID: <CAFtO3fnXVoCUOcsHFPsXGAuB363S_C0PFaFLqOg8SYmppYOztg@mail.gmail.com>

2011/10/26 Ivan Petrov <i.petro.77.00 на gmail.com>:
>> И как у этого велосипеда с производительностью на больших объёмах данных?
>
> Сильно лучше чем у DBIC. Запросы человек пишет много качественнее
> DBIC. Даже тупой человек.
>
SQL::Abstract сейчас хотят заменить на Data::Query, что должно
улучшить генератор SQL.

М.б. вы много хотите от ORM?

> ну а по сравнению с чистым DBI оверхед относительно небольшой:
> поскольку синтаксис "велосипеда" несложный, то там относительно
> простыми регулярками замены делаются.
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
WBR, Yury Pats
skype: yuripats
cellular: +375 (29) 5870723

From i.petro.77.00 на gmail.com  Wed Oct 26 10:23:29 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Wed, 26 Oct 2011 21:23:29 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <0BF3245D-1EAF-4B92-B002-6EF6EE15F81D@kostenko.name>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<0BF3245D-1EAF-4B92-B002-6EF6EE15F81D@kostenko.name>
Message-ID: <20111026172329.GH14585@apache.rbscorp.ru>

> Вы готовите его неправильно

да по всякому пробовали

> 1. Нужно подменять storage, а не модель.

в этом случае ОЧЕНЬ сложные тесты получаются.
модель может экспортировать 2 функции. их подменить - в тесте написать
две функции.
в storage может оказаться что надо подменять 10-20 функций.

> 2. Если правильно выбирать has_one/belongs_to, то join_type => 'left' нужен в исключительных случаях

иногда да, иногда нет

> 3. К сожалению, да. DBIx::Class работает хорошо только с хорошей структурой БД. Когда все просто и не нужно делать SQL-извращений для получения результата.

хорошая структура она тоже вещь редкодостижима. причем в силу зачастую
объективных причин, как-то сознательная денормализация, заради
быстродействия. требования к хранению сложнозависимых объектов итп

получается что "хорошая структура" она удерживается в БД пока проект
еще почти ничего в себя не включает.

From i.petro.77.00 на gmail.com  Wed Oct 26 10:25:50 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Wed, 26 Oct 2011 21:25:50 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <CAFtO3fn13sErnp6cdLHvynczdL6Osx+m82BjucTu+P4Y1Laj4w@mail.gmail.com>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<CANVWn7EEjv7_OGN8FmXGb7hruq_R9LW+1iuOFPwNP7bNugKcuQ@mail.gmail.com>
	<CAFtO3fn13sErnp6cdLHvynczdL6Osx+m82BjucTu+P4Y1Laj4w@mail.gmail.com>
Message-ID: <20111026172549.GI14585@apache.rbscorp.ru>

>> И как у этого велосипеда с производительностью на больших объёмах данных?
>> 
> Расскажи лучше нам про велосипед из патченного CDBI :)

> Но вопрос задан правильно. Универсальное решение не будет шустро
> работать при полноценном использовании его универсальности.

именно поэтому мы решили отказаться от универсального решения DBIC и
заменить его простым помощником, который выполнять будет немного
задач:
1 разделение SQL и perl по разным файлам
2 шаблон для блессинга выборки в расширяемые объекты
3 именованные плейсхолдеры с условиями

From i.petro.77.00 на gmail.com  Wed Oct 26 10:28:56 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Wed, 26 Oct 2011 21:28:56 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <CANVWn7Ey6nHo2P5_hpd3Vb6123pRrN4jrp3mR+HqmCW+nmspDw@mail.gmail.com>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<CANVWn7EEjv7_OGN8FmXGb7hruq_R9LW+1iuOFPwNP7bNugKcuQ@mail.gmail.com>
	<20111026165318.GG14585@apache.rbscorp.ru>
	<CANVWn7Ey6nHo2P5_hpd3Vb6123pRrN4jrp3mR+HqmCW+nmspDw@mail.gmail.com>
Message-ID: <20111026172855.GJ14585@apache.rbscorp.ru>

> А можно данные каких-нибудь тестов привести в доказательство этого тезиса? А то

будут, если проект попадет на CPAN.


> у меня очень сильное чувство, что этот велосипед работает только в этом проекте
> и ни разу не универсален.

пока он работает только в одном проекте это да.
ну да я этого и не скрывал.

мне интересно было бы если кто 
1. укажет ссылки на имеющийся проект из за которого эту работу и
доделывать не стоит, поскольку она уже кем-то сделана до нас
2. покритиковал бы описанный подход.



From i.petro.77.00 на gmail.com  Wed Oct 26 10:31:55 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Wed, 26 Oct 2011 21:31:55 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <CAFtO3fnXVoCUOcsHFPsXGAuB363S_C0PFaFLqOg8SYmppYOztg@mail.gmail.com>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<CANVWn7EEjv7_OGN8FmXGb7hruq_R9LW+1iuOFPwNP7bNugKcuQ@mail.gmail.com>
	<20111026165318.GG14585@apache.rbscorp.ru>
	<CAFtO3fnXVoCUOcsHFPsXGAuB363S_C0PFaFLqOg8SYmppYOztg@mail.gmail.com>
Message-ID: <20111026173155.GK14585@apache.rbscorp.ru>

>> Сильно лучше чем у DBIC. Запросы человек пишет много качественнее
>> DBIC. Даже тупой человек.
>> 
> SQL::Abstract сейчас хотят заменить на Data::Query, что должно
> улучшить генератор SQL.

http://search.cpan.org/~mstrout/Data-CapabilityBased-0.001000/lib/Data/Query.pm

оно?

> М.б. вы много хотите от ORM?

я думал с внедрением ORM у нас упростится работа с БД. в итоге она
усложнилась. я хочу ее все-таки упростить

From postmaster на softsearch.ru  Wed Oct 26 10:34:00 2011
From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=)
Date: Wed, 26 Oct 2011 21:34:00 +0400
Subject: [Moscow.pm] =?koi8-r?b?98/Q0s/TINDSzyDX2cvB1NnXwc7JxSDOz9fPx88g?=
	=?koi8-r?b?y8/EwSBbT0ZUT1BJQ10=?=
Message-ID: <209616750.20111026213400@softsearch.ru>

Здравствуйте.

Есть  ли  в  svn  возможность подставлять в текст файла ревижн другого
файла?

Проблема  такая:  нужно  подставить  в одном html-файле в урл загрузки
js-файла  что-то,  что  менялось бы при изменении js-файла. Т.е. чтобы
после выкатки нового кода в инет юзеры тут же качнули новый js-файл.

Это  можно  сделать  в  скрипте  выкатки.  Но  может есть ещё какие-то
варианты? Как подобные проблемы решаются Вами?

-- 
С уважением,
 Михаил                          mailto:postmaster на softsearch.ru


From i.petro.77.00 на gmail.com  Wed Oct 26 10:40:31 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Wed, 26 Oct 2011 21:40:31 +0400
Subject: [Moscow.pm] =?utf-8?b?0JLQvtC/0YDQvtGBINC/0YDQviDQstGL0LrQsNGC?=
 =?utf-8?b?0YvQstCw0L3QuNC1INC90L7QstC+0LPQviDQutC+0LTQsCBbT0ZUT1BJQ10=?=
In-Reply-To: <209616750.20111026213400@softsearch.ru>
References: <209616750.20111026213400@softsearch.ru>
Message-ID: <20111026174030.GL14585@apache.rbscorp.ru>

> Здравствуйте.

> Есть  ли  в  svn  возможность подставлять в текст файла ревижн другого
> файла?

> Проблема  такая:  нужно  подставить  в одном html-файле в урл загрузки
> js-файла  что-то,  что  менялось бы при изменении js-файла. Т.е. чтобы
> после выкатки нового кода в инет юзеры тут же качнули новый js-файл.

> Это  можно  сделать  в  скрипте  выкатки.  Но  может есть ещё какие-то
> варианты? Как подобные проблемы решаются Вами?

у нас тоже в одном проекте js'ы включаются в виде урлов

http://domain.com/path/to.js?svn_revison

а svn-ревизию берем из .svn/entries из четвертой строки

From jt на aaanet.ru  Wed Oct 26 10:53:46 2011
From: jt на aaanet.ru (=?utf-8?B?0JXQstCz0LXQvdC40Lkg0KLQvtGA0L7Qv9C+0LI=?=)
Date: Wed, 26 Oct 2011 21:53:46 +0400
Subject: [Moscow.pm] =?utf-8?b?0JLQvtC/0YDQvtGBINC/0YDQviDQstGL0LrQsNGC?=
 =?utf-8?b?0YvQstCw0L3QuNC1INC90L7QstC+0LPQviDQutC+0LTQsCBbT0ZUT1BJQ10=?=
In-Reply-To: <209616750.20111026213400@softsearch.ru>
References: <209616750.20111026213400@softsearch.ru>
Message-ID: <3FC28C70-18AF-4683-9066-FD3C2E124215@aaanet.ru>

У нас на уровне шаблонного движка есть конструкция

<%merge_files%>
<script type="text/javascript" src="..."></script>
<script type="text/javascript" src="..."></script>
<script type="text/javascript" src="..."></script>
<%/merge_files%>

проверяющая время последнего изменения каждого js-файла и компилируемая в нечто вроде

<script src="path/202cb962ac59075b964b07152d234b7.js?__m=1319460462" type="text/javascript"></script>

где __m и есть это самое время.

Евгений
jt на aaanet.ru

On Oct 26, 2011, at 9:34 PM, Михаил Монашёв wrote:

> Здравствуйте.
> 
> Есть  ли  в  svn  возможность подставлять в текст файла ревижн другого
> файла?
> 
> Проблема  такая:  нужно  подставить  в одном html-файле в урл загрузки
> js-файла  что-то,  что  менялось бы при изменении js-файла. Т.е. чтобы
> после выкатки нового кода в инет юзеры тут же качнули новый js-файл.
> 
> Это  можно  сделать  в  скрипте  выкатки.  Но  может есть ещё какие-то
> варианты? Как подобные проблемы решаются Вами?
> 
> -- 
> С уважением,
> Михаил                          mailto:postmaster на softsearch.ru
> 
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org


From meettya на gmail.com  Wed Oct 26 14:36:46 2011
From: meettya на gmail.com (Dmitry Karpich)
Date: Thu, 27 Oct 2011 01:36:46 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <20111026173155.GK14585@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<CANVWn7EEjv7_OGN8FmXGb7hruq_R9LW+1iuOFPwNP7bNugKcuQ@mail.gmail.com>
	<20111026165318.GG14585@apache.rbscorp.ru>
	<CAFtO3fnXVoCUOcsHFPsXGAuB363S_C0PFaFLqOg8SYmppYOztg@mail.gmail.com>
	<20111026173155.GK14585@apache.rbscorp.ru>
Message-ID: <6A255BE7-21D1-432D-9BBE-68D0C8ADA783@gmail.com>


On Oct 26, 2011, at 9:31 PM, Ivan Petrov wrote:
> 
> я думал с внедрением ORM у нас упростится работа с БД. в итоге она
> усложнилась. я хочу ее все-таки упростить

Очень интересный проект, однозначно допиливать и в общественность, по моей памяти реализованы именно те вещи, которые обычно нужны.

А вот с ORM никогда не связывался, и все попытки автоматизирования и "заворачивания" кода во что-то обычно у нас заканчивались monkey-patch-ингом "втихую", потому что "да елы-палы, тупая фихня!".

ИМХО - ну нельзя "без швов" склеить SQL и что-то еще, да, это отдельный и самостоятельный язык. Любая попытка скрыть его дает неюзабельное нечто, которое или слишком простое и им невозможно пользоваться, или слишком сложное и им нереально пользоваться.

Митяй.

PS. ага, на гитхаб бы, с удовольствием форкнул бы да поковырял.


> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org


From mons на rambler-co.ru  Wed Oct 26 14:59:02 2011
From: mons на rambler-co.ru (Mons Anderson)
Date: Thu, 27 Oct 2011 01:59:02 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <CAFtO3fn13sErnp6cdLHvynczdL6Osx+m82BjucTu+P4Y1Laj4w@mail.gmail.com>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<CANVWn7EEjv7_OGN8FmXGb7hruq_R9LW+1iuOFPwNP7bNugKcuQ@mail.gmail.com>
	<CAFtO3fn13sErnp6cdLHvynczdL6Osx+m82BjucTu+P4Y1Laj4w@mail.gmail.com>
Message-ID: <D5FC62F9-960C-4B27-84A9-25CFE9A8FFCE@rambler-co.ru>


>>> соответственно вопросы:
>>> 
>>> 1. кому-нибудь интересна подобная система, стоит класть на CPAN?
> Выкладывайте хотя бы на гитхаб!
> 

Поддерживаю.
Для начала на гитхаб.

From akzhan.abdulin на gmail.com  Wed Oct 26 22:30:12 2011
From: akzhan.abdulin на gmail.com (Akzhan Abdulin)
Date: Thu, 27 Oct 2011 09:30:12 +0400
Subject: [Moscow.pm] =?utf-8?b?0JLQvtC/0YDQvtGBINC/0YDQviDQstGL0LrQsNGC?=
	=?utf-8?b?0YvQstCw0L3QuNC1INC90L7QstC+0LPQviDQutC+0LTQsCBbT0ZUT1BJ?=
	=?utf-8?q?C=5D?=
In-Reply-To: <209616750.20111026213400@softsearch.ru>
References: <209616750.20111026213400@softsearch.ru>
Message-ID: <CAGOcgF28KqNs5doYwZNSKYwYenzNX9niDKaT42JDAobz4pS3Qg@mail.gmail.com>

deploy "project" do
  ...
  to "/var/www/project"
end

или

cap production deploy

при этом в шаблонных файлах прописываем время модификации шаблона.

поскольку новая ревизия выкладывается не поверх старой, я рядом, время
модификации всех файлов одно и то же.

26 октября 2011 г. 21:34 пользователь Михаил Монашёв <
postmaster на softsearch.ru> написал:

> Здравствуйте.
>
> Есть  ли  в  svn  возможность подставлять в текст файла ревижн другого
> файла?
>
> Проблема  такая:  нужно  подставить  в одном html-файле в урл загрузки
> js-файла  что-то,  что  менялось бы при изменении js-файла. Т.е. чтобы
> после выкатки нового кода в инет юзеры тут же качнули новый js-файл.
>
> Это  можно  сделать  в  скрипте  выкатки.  Но  может есть ещё какие-то
> варианты? Как подобные проблемы решаются Вами?
>
> --
> С уважением,
>  Михаил                          mailto:postmaster на softsearch.ru
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111027/16567673/attachment.html>

From akzhan.abdulin на gmail.com  Wed Oct 26 23:07:09 2011
From: akzhan.abdulin на gmail.com (Akzhan Abdulin)
Date: Thu, 27 Oct 2011 10:07:09 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111026162647.GF14585@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
Message-ID: <CAGOcgF00x04Kr7-wn-5LeJXLKMkHQQU8q9GwOPqr0xc3wbFhMg@mail.gmail.com>

1) проблем с DBIx::Class не наблюдал. возможно, потому что делал всё на
новом проекте с новой же структурой БД.
2) любая публичная разработка начинается с GitHub, CPAN первое время точно
не нужен.

26 октября 2011 г. 20:26 пользователь Ivan Petrov
<i.petro.77.00 на gmail.com>написал:

> сделали мы тут цельный проект на DBIx::Class. С точки зрения
> попробовать последний. До этого всегда использовали DBI, который
> использовала модель в системе MVC.
>
> Впечатления плохие, однако появились мысли куда надо двигаться чтобы
> было хорошо. Я их тут изложу, а вы покритикуйте.
>
> В первую очередь зачем как бы нужен был этот DBIC.
>  - конструирование SQL-запросов
>  - уход от смешивания кода Perl с кодом SQL
>  - выборка объектов, а не хешей из БД, которые можно расширять своими
>   методами
>  - упрощение кода моделей с точки зрения что в простых случаях вообще
>   не делать выделенную модель
>
> Ничего не забыл?
>
> По результатам проекта (проект был довольно большой и дальше еще будет
> долго) я понял следующее:
>
> 1. даже в простых случаях DBIC на роль модели не годится. То есть в
> любом случае нужно делать выделенную модель, пусть даже там один
> resultset('Name')->find. Ибо тесты. При их написании мы применяем
> способ "подменить модель на стадии тестирования".
>
> 2. DBIC не предоставляет хорошей абстракции над БД. Все равно
> JOIN'ы, SELECT'ы торчат местами (например join_type => 'left' в has'ах
> итп). То есть оперировать хранилищем как некоей абстракцией в реальном
> случае не получается.
>
> 3. Конструктор SQL-запросов крайне страшен. Работали мы с постоянно
> включенной отладкой (выводом всех делающихся запросов в лог). С одной
> стороны есть множество вещей которые на DBIC сделать крайне непросто
> (например многие аггрегаторные вещи), с другой стороны когда
> начинается работа с более чем двумя таблицами он зачастую мутит такие
> страшные вложенные SQL-запросы что волосы дыбом становятся, а с
> третьей стороны использование фич конкретной БД становится затруднено.
>
> В итоге пришли к тому, что в сложных случаях приходится делать в БД
> view'ы только из за того что от DBIC добиться генерации нормального
> запроса очень и очень сложно или невозможно. Набор опций при выборке
> может быть больше самого SQL-запроса, если его просто написать.
>
> Ну вот и в свете того, что код работы с DBIC все равно располагается в
> моделях, конструировать эффективные SQL-запросы он все равно не умеет,
> то из плюсов его использования остаются только:
>  - выборка в объекты и итераторы по ним
>  - уход от смешивания Perl и SQL
>
> Соответственно размышляя над всем этим мы пришли к тому, что
>
> 1. построить качественный автогенератор SQL запросов на все случаи
> жизни (или по кр. мере на большинство) невозможно, поэтому его не
> стоит и пытаться сделать
>
> 2. из за п.1 бОльшая часть DBIC становится не нужна, а надо делать
> некоего помощника, который бы человеку просто помогал удобно работать
> с БД.
>
> то есть надо
>
> 1. написать свой итератор, работающий поверх массива или
> хеша - выборки из БД.
> 2. написать базовую обертку над одной строкой выборки (доступ в виде
> методов)
> 3. Используя 1 и 2 написать над DBI класс, который выборки блессает в
> итераторы и объекты
> 4. решить вопрос с выносом SQL-кода из перловых модулей. То есть
> обертка 3 должна уметь работать с SQL, располагающимися в файлах.
>
>
> Вынос SQL в файлы очень плохо соотносится с дефолтными плейсхолдерами
> DBI. поскольку они позиционные.
>
> Вывод:
> 5. надо реализовывать именованные плейсхолдеры
>
> ну и попутно
> 5.1 реализовать плейсхолдерные (темплейтные) выражения для типовых
> вещей, как-то
>  INSERT ... VALUES (?,?,?),(?,?,?),(?,?,?),...
>
> или
>  SELECT ... WHERE id IN (?,?,?)
>
> то есть подстановки массивов.
>
> Соответственно исходя из этого родился набор модулей, который в
> ближайшее время, если кому-то будет интересно, мы можем выложить на
> CPAN (там еще работы на неск. дней осталось), который все это делает:
>
> 1. по дефолту блесает строки-выборки в объект, у которого три
> предопределенных метода: new, is_changed, iterator. Плюс методы
> совпадающие с именами выбранных столбиков.
>
> 2. блесает наборы-выборки в объект позволяющий делать проходы по
> выборкам итп (совместимо с DBIC'шными ->all, while(...->next) итп
>
> 3. в п. 1 и 2 позволяет указывать свои классы для итераторов и выборок
>
> 4. позволяет вместо SQL использовать имена файлов SQL в предзаданной
> директории (по аналогии с темлейтами любого вебпроекта)
>
> 5. реализует следующий набор подстановок в SQL
>
>    ?{путь} - просто подставляет переменную
>    ?@{путь} - подставляет массив переменных (через запятую)
>    ?%{путь}{поле,поле,...} - подставляет массив переменных (через
>          запятую) из массива хешей
>
>    ну и на вс случай сделали
>    ?sub{перловый код}
>
>
>    А так же набор условных подстановок вроде
>
>    ?if[de]?{путь}{ блок который вставится }{else-блок}
>
>    условия - if - истина
>              ifd - определен
>              ife - имеется
>
>   Блоки можно вкладывать друг в друга.
>
>   пути - по сути путь к переменной во входном хеше, то есть
>
>   $dbh->do($sql, values => { ids => [1, 3, 5] }, abc => 'def');
>
>   путями являются
>   'values'
>   'abc'
>   'values.ids'
>
>   и так далее.
>
>   поддерживаются в путях и объекты
>
>   path.to:method  - будет вызван метод объекта, а значение им
>   возвращенное будет вставлено в SQL.
>
>
> В итоге что получили:
>
> 1. SQL вынесен в отдельный каталог (отдельные каталоги) примерно так
> же как вынесены темплейты в любом вебпроекте
> 2. типичные SQL-вещи делаются просто. Сложные тоже можно делать.
> 3. Поскольку итератор по именам методов постарались сделать
> совместимым с DBIC то замена одного на другое не вызывает больших
> трудностей.
>
> ну и возьмем пример:
>
> скажем приходит от пользователя форма
>
> $filters = { region => 'Москва', street => '' };
>
> То есть он фильтр по региону заполнил, а фильтр по улице нет
>
> запрос может выглядеть так
>
> SELECT
>    *
> FROM
>    tbl1
> LEFT JOIN tbl2 ...
>
> WHERE
>    something = ..
>
>    ?if{filters.region}{ AND region = ?{filters.region} }
>    ?if{filters.street}{ AND street = ?{filters.street} }
>
> и так далее.
>
> Получается SQL перестраивается в зависимости от того что там вводит
> пользователь.
>
> Осталось нерешенными некоторые типовые вопросы, но мы их планируем
> порешать в ближайшее время (например подставновки частей в
> like-секции)
>
> соответственно вопросы:
>
> 1. кому-нибудь интересна подобная система, стоит класть на CPAN?
> 2. может на эту тему есть что-то готовое да мы велик очередной ваяем?
> тогда ткните указкой:)
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111027/35ea2ca2/attachment-0001.html>

From yu.pats на gmail.com  Thu Oct 27 01:18:14 2011
From: yu.pats на gmail.com (Yury Pats)
Date: Thu, 27 Oct 2011 11:18:14 +0300
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111026173155.GK14585@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<CANVWn7EEjv7_OGN8FmXGb7hruq_R9LW+1iuOFPwNP7bNugKcuQ@mail.gmail.com>
	<20111026165318.GG14585@apache.rbscorp.ru>
	<CAFtO3fnXVoCUOcsHFPsXGAuB363S_C0PFaFLqOg8SYmppYOztg@mail.gmail.com>
	<20111026173155.GK14585@apache.rbscorp.ru>
Message-ID: <CAFtO3fkCzcy5A-FKSRyeftucCnTu2Ut8nYJOovxt2U607C3wkg@mail.gmail.com>

2011/10/26 Ivan Petrov <i.petro.77.00 на gmail.com>:
>>> Сильно лучше чем у DBIC. Запросы человек пишет много качественнее
>>> DBIC. Даже тупой человек.
>> SQL::Abstract сейчас хотят заменить на Data::Query, что должно
>> улучшить генератор SQL.
> http://search.cpan.org/~mstrout/Data-CapabilityBased-0.001000/lib/Data/Query.pm
> оно?

Судя по автору, да. Мэтт выступал с соотв. докладом на япси в Риге,
http://yapceurope.lv/ye2011/talk/3314
Видео в этом году не дождемся, наверное :) Сам помечал себе погуглить
на эту тему, но до сих пор не взялся.

>> М.б. вы много хотите от ORM?
> я думал с внедрением ORM у нас упростится работа с БД. в итоге она
> усложнилась. я хочу ее все-таки упростить
Да, это первый подводный камень использования ORM: внеднение ORM не панацея.

А вообще на своей памяти не припомню готовых велосипедов, использующих
SQL-шаблоны и именованный маппинг, в т.ч. и массивов. Показывайте,
будет интересно.

-- 
WBR, Yury Pats
skype: yuripats
cellular: +375 (29) 5870723

From worldmind на mail.ru  Thu Oct 27 03:16:34 2011
From: worldmind на mail.ru (Alexey Shrub)
Date: Thu, 27 Oct 2011 14:16:34 +0400
Subject: [Moscow.pm]
 =?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
 =?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <20111026162647.GF14585@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
Message-ID: <1319710594.2051.13.camel@host>

On Ср., 2011-10-26 at 20:26 +0400, Ivan Petrov wrote:
> 1. кому-нибудь интересна подобная система, стоит класть на CPAN?

В ближайшее время что-то такое понадобится, так что буду рад если оно
попадёт на github/cpan


From andrei.protasovitski на gmail.com  Thu Oct 27 03:59:00 2011
From: andrei.protasovitski на gmail.com (Andrei)
Date: Thu, 27 Oct 2011 12:59:00 +0200
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <CAFtO3fn13sErnp6cdLHvynczdL6Osx+m82BjucTu+P4Y1Laj4w@mail.gmail.com>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<CANVWn7EEjv7_OGN8FmXGb7hruq_R9LW+1iuOFPwNP7bNugKcuQ@mail.gmail.com>
	<CAFtO3fn13sErnp6cdLHvynczdL6Osx+m82BjucTu+P4Y1Laj4w@mail.gmail.com>
Message-ID: <CANVWn7ESD9esSL-wCdCSDm=oe1Ay==jpnwnKGhqt+b1dLOCoBw@mail.gmail.com>

26 октября 2011 г. 19:13 пользователь Yury Pats <yu.pats на gmail.com> написал:

> 2011/10/26 Andrei <andrei.protasovitski на gmail.com>:
> > И как у этого велосипеда с производительностью на больших объёмах данных?
> >
> Расскажи лучше нам про велосипед из патченного CDBI :)
>

Что именно тебя интересует? Там не так много патчено: 1) работа напрямую с
мастером, 2) оптимизация работы с большими вставками, 3) кое-где оптимизация
скорости без изменения API, 4) что-то там для транзакций, 5) наверное,
что-то ещё, но я не заморачивался. :)

-- 
Andrei Protasovitski
< andrei[dot]protasovitski[at]gmail[dot]com >
Diemen, Netherlands
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111027/42293d1a/attachment.html>

From andrei.protasovitski на gmail.com  Thu Oct 27 04:01:09 2011
From: andrei.protasovitski на gmail.com (Andrei)
Date: Thu, 27 Oct 2011 13:01:09 +0200
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111026172855.GJ14585@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<CANVWn7EEjv7_OGN8FmXGb7hruq_R9LW+1iuOFPwNP7bNugKcuQ@mail.gmail.com>
	<20111026165318.GG14585@apache.rbscorp.ru>
	<CANVWn7Ey6nHo2P5_hpd3Vb6123pRrN4jrp3mR+HqmCW+nmspDw@mail.gmail.com>
	<20111026172855.GJ14585@apache.rbscorp.ru>
Message-ID: <CANVWn7GZQPvBSnh6zYe7mJ07fU+ZEstN5YNtz6BhzXyFxyHqQw@mail.gmail.com>

26 октября 2011 г. 19:28 пользователь Ivan Petrov
<i.petro.77.00 на gmail.com>написал:

> > А можно данные каких-нибудь тестов привести в доказательство этого
> тезиса? А то
>
> будут, если проект попадет на CPAN.
>

Меня интересуют тесты производительности, а не юнит-тесты. Они могут (и
должны) проводиться до выкладывания в production, даже до CPAN.

-- 
Andrei Protasovitski
< andrei[dot]protasovitski[at]gmail[dot]com >
Diemen, Netherlands
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111027/79458c62/attachment.html>

From citrin на citrin.ru  Thu Oct 27 04:03:20 2011
From: citrin на citrin.ru (Anton Yuzhaninov)
Date: Thu, 27 Oct 2011 15:03:20 +0400
Subject: [Moscow.pm]
 =?koi8-r?b?98/Q0s/TINDSzyDX2cvB1NnXwc7JxSDOz9fPx88g?=
 =?koi8-r?b?y8/EwSBbT0ZUT1BJQ10=?=
In-Reply-To: <209616750.20111026213400@softsearch.ru>
References: <209616750.20111026213400@softsearch.ru>
Message-ID: <4EA93A78.1090408@citrin.ru>

On 10/26/11 21:34, Михаил Монашёв wrote:
> Есть  ли  в  svn  возможность подставлять в текст файла ревижн другого
> файла?
>
> Проблема  такая:  нужно  подставить  в одном html-файле в урл загрузки
> js-файла  что-то,  что  менялось бы при изменении js-файла. Т.е. чтобы
> после выкатки нового кода в инет юзеры тут же качнули новый js-файл.

Насколько знаю нет, так что остается это делать на этапе пост-обработки.

Тут сложность не в проставлении ревизии, а в построении графа всех зависимостей.

Например обновилась картинка x.png, которая используется в y.css.

Нужно поменять uri внутри css файла на
x_png_rev/x.png
но этого мало
нужно внутри всех html-файлов, использующих y.css поменять uri к y.css на новый 
(потому что в старом css ссылки на старый png).

Либо есть совсем простой вариант - при выкатке менять версию всех статических 
файлов. Минус такого варианта - при выкатке будут перезагружены все файлы, даже 
которые не менялись, но если выкатка случается редко, то это допустимо.
Зато нигде не возникнет старого контента из за того, что где то не отследили 
зависимость (особенно сложно это делать в js, где URI формируется в коде). Такой 
вариант раньше использовался в R-почте - глобальный revision включался в префикс 
для всех статических ресурсов css/js/img (сейчас насколько вижу, там совсем нет 
версионирования статики).

-- 
  Anton Yuzhaninov

P. S. Если не видел, можешь глянуть доклад Скворцова на эту тему: 
http://www.slideshare.net/godegisel/rit-2011-eternal-static

From i.petro.77.00 на gmail.com  Thu Oct 27 05:00:09 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Thu, 27 Oct 2011 16:00:09 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <CANVWn7GZQPvBSnh6zYe7mJ07fU+ZEstN5YNtz6BhzXyFxyHqQw@mail.gmail.com>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<CANVWn7EEjv7_OGN8FmXGb7hruq_R9LW+1iuOFPwNP7bNugKcuQ@mail.gmail.com>
	<20111026165318.GG14585@apache.rbscorp.ru>
	<CANVWn7Ey6nHo2P5_hpd3Vb6123pRrN4jrp3mR+HqmCW+nmspDw@mail.gmail.com>
	<20111026172855.GJ14585@apache.rbscorp.ru>
	<CANVWn7GZQPvBSnh6zYe7mJ07fU+ZEstN5YNtz6BhzXyFxyHqQw@mail.gmail.com>
Message-ID: <20111027120009.GM14585@apache.rbscorp.ru>


>> А можно данные каких-нибудь тестов привести в доказательство этого
> тезиса? А то

> будут, если проект попадет на CPAN.

> Меня интересуют тесты производительности, а не юнит-тесты. Они могут (и должны)
> проводиться до выкладывания в production, даже до CPAN.

тут сравнивать то собственно не с чем.

сравнивать с DBI? этот модуль является над ним надстройкой, то есть
делает предобработку данных перед трансляцией ему, соответственно
будет всегда медленнее DBI работать.

сранивать с DBIC? DBIC делает:
1. генерацию запросов
2. генерацию запросов некачественных (с точки зрения
производительности SQL)
3. POST-обработку выборки и сплит ее в объекты (мы отказываемся
от этого сразу, ибо поскольку исключаем кривые запросы, то и
POST-обработка не нужна: то есть в нашем случае получается код в
предельном случае, состоящий из одной инструкции bless).

то есть узкое место в случае с DBIC будет база данных, которая его
кривые запросы будет мучиться исполнять.

соответственно единственные тесты производительности о которых можно
говорить это тесты "как быстро работает темплейтный парсер".

ну вот есть такой тестик.

    SELECT
        u.*
    FROM
        users AS u

    ?if{filters.role_name} {
        LEFT JOIN roles AS r ON u.rid = r.id
    }

    ?if{filters.user_name} {
        LEFT JOIN user_cards AS uc ON u.id = uc.uid
    }

    WHERE
        1 = 1

    ?if{filters.role_name} {
        AND r.name = ?{ filters.role_name }
    }

    ?if{filters.user_name} {
        AND uc.name = ?{ filters.user_name }
    }


на 1 = 1 пока не смотрим :), сейчас работаем над тем чтобы добавить
оператор для таких случаев. Соответственно тут вариантов обработки
данного запроса три:

1. Все фильтры включены (будет два JOIN'а)
2. Включен один из двух фильтров
3. Все фильтры выключены

времена предобработки такого запроса (после этого управление уйдет в
DBI) такие:

=cut

Two active filters
 1 wallclock secs ( 1.21 usr +  0.00 sys =  1.21 CPU) @ 8264.46/s (n=10000)
One active filter
 1 wallclock secs ( 1.03 usr +  0.00 sys =  1.03 CPU) @ 9708.74/s (n=10000)
No active filters
 1 wallclock secs ( 0.82 usr +  0.00 sys =  0.82 CPU) @ 12195.12/s (n=10000)

=cut


машинка, на которой это делается - P4/1600.

Отсюда видно, что узкое место тут явно будет БД (которая 8000
запросов на данном железе не сделает никогда), а не предобработчик
SQL.

PS: рисование более сложных запросов конечно приведет к большим
временам на предобработку, но очевидно, что более сложные запросы и БД
будет выполнять более долго. это первое.

второе: как ни крути, в рассматриваемом случае SQL-запросов будет три
для трех случаев: введен один фильтр, введено оба, не введен ни один.

и предобработка в этом случае требуется всегда. бесплатной она не
будет ни в каком варианте

From andrei.protasovitski на gmail.com  Thu Oct 27 05:57:31 2011
From: andrei.protasovitski на gmail.com (Andrei)
Date: Thu, 27 Oct 2011 14:57:31 +0200
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111027120009.GM14585@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<CANVWn7EEjv7_OGN8FmXGb7hruq_R9LW+1iuOFPwNP7bNugKcuQ@mail.gmail.com>
	<20111026165318.GG14585@apache.rbscorp.ru>
	<CANVWn7Ey6nHo2P5_hpd3Vb6123pRrN4jrp3mR+HqmCW+nmspDw@mail.gmail.com>
	<20111026172855.GJ14585@apache.rbscorp.ru>
	<CANVWn7GZQPvBSnh6zYe7mJ07fU+ZEstN5YNtz6BhzXyFxyHqQw@mail.gmail.com>
	<20111027120009.GM14585@apache.rbscorp.ru>
Message-ID: <CANVWn7FtxENdU5g2it9hGCoqiHExFQa3WH0G+CbOkTrZvYGvmw@mail.gmail.com>

27 октября 2011 г. 14:00 пользователь Ivan Petrov
<i.petro.77.00 на gmail.com>написал:

>
> >> А можно данные каких-нибудь тестов привести в доказательство этого
> > тезиса? А то
>
> > будут, если проект попадет на CPAN.
>
> > Меня интересуют тесты производительности, а не юнит-тесты. Они могут (и
> должны)
> > проводиться до выкладывания в production, даже до CPAN.
>
> тут сравнивать то собственно не с чем.
>
> сравнивать с DBI? этот модуль является над ним надстройкой, то есть
> делает предобработку данных перед трансляцией ему, соответственно
> будет всегда медленнее DBI работать.
>
> сранивать с DBIC? DBIC делает:
> 1. генерацию запросов
> 2. генерацию запросов некачественных (с точки зрения
> производительности SQL)
> 3. POST-обработку выборки и сплит ее в объекты (мы отказываемся
> от этого сразу, ибо поскольку исключаем кривые запросы, то и
>

Это неправда. Нормальный ORM возвращает итератор, а объекты создаёт только
когда они действительно нужны.


> POST-обработка не нужна: то есть в нашем случае получается код в
> предельном случае, состоящий из одной инструкции bless).
>
> то есть узкое место в случае с DBIC будет база данных, которая его
> кривые запросы будет мучиться исполнять.
>

Узкое место, как правило, между клавиатурой и спинкой кресла.


> соответственно единственные тесты производительности о которых можно
> говорить это тесты "как быстро работает темплейтный парсер".
>

Тогда надо сравнивать ваш велосипед с SQL::Abstract, а не с DBIC.


>
> ну вот есть такой тестик.
>
>    SELECT
>        u.*
>    FROM
>        users AS u
>
>    ?if{filters.role_name} {
>        LEFT JOIN roles AS r ON u.rid = r.id
>    }
>
>    ?if{filters.user_name} {
>        LEFT JOIN user_cards AS uc ON u.id = uc.uid
>    }
>
>    WHERE
>        1 = 1
>
>    ?if{filters.role_name} {
>        AND r.name = ?{ filters.role_name }
>    }
>
>    ?if{filters.user_name} {
>        AND uc.name = ?{ filters.user_name }
>    }
>

Всё, после этого запорса можно не читать. Ваша проблема не в ORM, а в том,
что вы не понимаете, для чего он нужен. Внимательно прочитайте, что написал
Andrii Kostenko ранее. А потом ещё раз. И ещё раз.

ORM -- это Object-relational mapping, а не конструктор запросов.

Удачи!
-- 
Andrei Protasovitski
< andrei[dot]protasovitski[at]gmail[dot]com >
Diemen, Netherlands
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111027/b261777f/attachment.html>

From postmaster на softsearch.ru  Thu Oct 27 08:33:55 2011
From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=)
Date: Thu, 27 Oct 2011 19:33:55 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
	=?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <20111026173155.GK14585@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<CANVWn7EEjv7_OGN8FmXGb7hruq_R9LW+1iuOFPwNP7bNugKcuQ@mail.gmail.com>
	<20111026165318.GG14585@apache.rbscorp.ru>
	<CAFtO3fnXVoCUOcsHFPsXGAuB363S_C0PFaFLqOg8SYmppYOztg@mail.gmail.com>
	<20111026173155.GK14585@apache.rbscorp.ru>
Message-ID: <1284952686.20111027193355@softsearch.ru>

Здравствуйте, Ivan.

>> М.б. вы много хотите от ORM?

> я думал с внедрением ORM у нас упростится работа с БД. в итоге она
> усложнилась. я хочу ее все-таки упростить

Знаете какая версия windows самая удобная? Та, в которой Вы работаете.

-- 
С уважением,
 Михаил                          mailto:postmaster на softsearch.ru


From akzhan.abdulin на gmail.com  Thu Oct 27 08:35:21 2011
From: akzhan.abdulin на gmail.com (Akzhan Abdulin)
Date: Thu, 27 Oct 2011 19:35:21 +0400
Subject: [Moscow.pm] =?utf-8?b?0JLQvtC/0YDQvtGBINC/0YDQviDQstGL0LrQsNGC?=
	=?utf-8?b?0YvQstCw0L3QuNC1INC90L7QstC+0LPQviDQutC+0LTQsCBbT0ZUT1BJ?=
	=?utf-8?q?C=5D?=
In-Reply-To: <CAGOcgF28KqNs5doYwZNSKYwYenzNX9niDKaT42JDAobz4pS3Qg@mail.gmail.com>
References: <209616750.20111026213400@softsearch.ru>
	<CAGOcgF28KqNs5doYwZNSKYwYenzNX9niDKaT42JDAobz4pS3Qg@mail.gmail.com>
Message-ID: <CAGOcgF2bZ7A58x-4ntjYQ9Ad6cma3AMfPiiCq1MyVY0502Ca_g@mail.gmail.com>

И да, меняются пути к файлам только на уровне http. Далее срабатывает
rewrite-правило в nginx:

location /js/ {
  rewrite (.+)\-v\d+\.js$ $1.js last;
  add_header Cache-Control private;
  expires max;
  alias /home/<>.com/www/js/;
}


27 октября 2011 г. 9:30 пользователь Akzhan Abdulin <
akzhan.abdulin на gmail.com> написал:

> deploy "project" do
>   ...
>   to "/var/www/project"
> end
>
> или
>
> cap production deploy
>
> при этом в шаблонных файлах прописываем время модификации шаблона.
>
> поскольку новая ревизия выкладывается не поверх старой, я рядом, время
> модификации всех файлов одно и то же.
>
> 26 октября 2011 г. 21:34 пользователь Михаил Монашёв <
> postmaster на softsearch.ru> написал:
>
> Здравствуйте.
>>
>> Есть  ли  в  svn  возможность подставлять в текст файла ревижн другого
>> файла?
>>
>> Проблема  такая:  нужно  подставить  в одном html-файле в урл загрузки
>> js-файла  что-то,  что  менялось бы при изменении js-файла. Т.е. чтобы
>> после выкатки нового кода в инет юзеры тут же качнули новый js-файл.
>>
>> Это  можно  сделать  в  скрипте  выкатки.  Но  может есть ещё какие-то
>> варианты? Как подобные проблемы решаются Вами?
>>
>> --
>> С уважением,
>>  Михаил                          mailto:postmaster на softsearch.ru
>>
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111027/52215c5f/attachment.html>

From yu.pats на gmail.com  Thu Oct 27 08:35:57 2011
From: yu.pats на gmail.com (Yury Pats)
Date: Thu, 27 Oct 2011 18:35:57 +0300
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <1284952686.20111027193355@softsearch.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<CANVWn7EEjv7_OGN8FmXGb7hruq_R9LW+1iuOFPwNP7bNugKcuQ@mail.gmail.com>
	<20111026165318.GG14585@apache.rbscorp.ru>
	<CAFtO3fnXVoCUOcsHFPsXGAuB363S_C0PFaFLqOg8SYmppYOztg@mail.gmail.com>
	<20111026173155.GK14585@apache.rbscorp.ru>
	<1284952686.20111027193355@softsearch.ru>
Message-ID: <CAFtO3fnPu8nU0J2yfS3rFGTHHtVsWFkYtM0c8yajA-zs6Ax-GQ@mail.gmail.com>

2011/10/27 Михаил Монашёв <postmaster на softsearch.ru>:
> Здравствуйте, Ivan.
>
>>> М.б. вы много хотите от ORM?
>
>> я думал с внедрением ORM у нас упростится работа с БД. в итоге она
>> усложнилась. я хочу ее все-таки упростить
>
> Знаете какая версия windows самая удобная?
>
Linux?

> --
> С уважением,
>  Михаил                          mailto:postmaster на softsearch.ru
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
WBR, Yury Pats
skype: yuripats
cellular: +375 (29) 5870723

From mi на ya.ru  Thu Oct 27 09:10:06 2011
From: mi на ya.ru (Nikolay Mishin)
Date: Thu, 27 Oct 2011 20:10:06 +0400
Subject: [Moscow.pm] =?koi8-r?b?5MXO2CDyz9bExc7Y0SBDUEFOLg==?=
Message-ID: <61011319731806@web124.yandex.ru>

Hi, Moscow-pm

тут коллеги из kiev-pm говорят, что 26 октября - день варенья CPAN, поздравляю!

Yaroslav Korshak ykorshak на gmail.com кому: kiev-perl-user.
Показать детали 26 окт (1 день назад)
Господа!

День Рожденья CPAN.
C 1995 года он служит программистам и администраторам верой и правдой, обростая модулями, фичами и интерфейсами.

Поздравляю всех нас!

Немного истории:
http://groups.google.com/group/comp.lang.perl.announce/browse_thread/thread/d6a94b1ddbe26656/fead47b2b9744f85

--
Regards
yko

--
Nikolay Mishin

From ruz на bestpractical.com  Thu Oct 27 09:19:04 2011
From: ruz на bestpractical.com (Ruslan Zakirov)
Date: Thu, 27 Oct 2011 20:19:04 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111026172329.GH14585@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<0BF3245D-1EAF-4B92-B002-6EF6EE15F81D@kostenko.name>
	<20111026172329.GH14585@apache.rbscorp.ru>
Message-ID: <CAMOxC8sOVrpPBqEfTowv_5xz1WxV69-Z2MidcQjJgGiAq8Jn4A@mail.gmail.com>

2011/10/26 Ivan Petrov <i.petro.77.00 на gmail.com>:
>> Вы готовите его неправильно
>
> да по всякому пробовали
>
>> 1. Нужно подменять storage, а не модель.
>
> в этом случае ОЧЕНЬ сложные тесты получаются.
> модель может экспортировать 2 функции. их подменить - в тесте написать
> две функции.
> в storage может оказаться что надо подменять 10-20 функций.

Замечание только по тестированию. БД - ключевой элемент в вашем
проекте. Так? Если так, то я просто не вижу смысла использовать
подделку ответов. Нужно создавать тестовые БД. Можно их создавать из
дампов или создавать записи прямо в тестах. Mocking - это последнее
дело в тестировании. К нему нужно прибегать только, когда невозможно
создать ситуацию искусственно. Для примера: нужно оттестировать
реакцию на ошибку, которая проявлялась только в версии X внешнего
компонента и приводила к плачевным результатам.

Есть разумные применения mocking'а, но интерфейс между БД и
приложением к ним не относится.

-- 
Best regards, Ruslan.

From rabbit+moscowpm на rabbit.us  Thu Oct 27 10:22:19 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Thu, 27 Oct 2011 13:22:19 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111026162647.GF14585@apache.rbscorp.ru>
Message-ID: <20111027172219.GA13125@rabbit.us>

Господа! Зачем Вы травите?! ;)

Времени у меня в обрез, так что буду очен резким и кратким. Сначала отвечаю
на некоторые пункты:

> 1. построить качественный автогенератор SQL запросов на все случаи
> жизни (или по кр. мере на большинство) невозможно, поэтому его не
> стоит и пытаться сделать

FUD. С таким настроем ни PPI ни Moose и вообще много еще чего никогда бы не
появилось.

> Сильно лучше чем у DBIC. Запросы человек пишет много качественнее
> DBIC. Даже тупой человек.

и

> 3. Конструктор SQL-запросов крайне страшен. Работали мы с постоянно
> включенной отладкой (выводом всех делающихся запросов в лог). С одной
> стороны есть множество вещей которые на DBIC сделать крайне непросто
> (например многие аггрегаторные вещи), с другой стороны когда
> начинается работа с более чем двумя таблицами он зачастую мутит такие
> страшные вложенные SQL-запросы что волосы дыбом становятся, а с
> третьей стороны использование фич конкретной БД становится затруднено.

Я на 95% уверен что здесь проблема в недопонемании API. Запрос к самому
DBIC был сконструирован таким образом что без вложеных запросов достат
все просто невозможно. Осталные 5% - баги. Баги которые неимоверно трудно
исправить, потому что никто о них не долкадывает. Что приводит нас к
главной теме:

SHOW US THE CODE! :) По нескольку раз в год, в каком то углу интернета
поднимается вой что проект X тяжел, глуп, и вобще отстой. Попытки докопатся
"а в чем собственно дело" обычно заканчиваются печалным посылом на буквы
обеими сторонами. И так до следующего раза. Так что давайте конструктивнее,
а там видать все довольными останемся :)

Для начала - выложите search() с аргументами, и какой SQL был в результате
наворочен. Для дополнительного бонуса - предложите каким SQL можно бы было
все заменить.

Жду с нетерпением, ибо охота разделатся с проблемами и нашими и чужими :)

Cheers

From i.petro.77.00 на gmail.com  Thu Oct 27 13:05:31 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 00:05:31 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <20111027172219.GA13125@rabbit.us>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
Message-ID: <20111027200530.GP14585@apache.rbscorp.ru>


> По нескольку раз в год, в каком то углу интернета
> поднимается вой что проект X тяжел, глуп, и вобще отстой.

я не говорил что DBIC глуп, тем паче что тяжел

я говорю:

1. DBIC пытаются решить принципиально нерешаемую задачу (впрочем когда
изобретут AI задача станет решаемой). В силу этого задачки чуть
сложнее двух таблиц для него становятся трудноразрешимыми
2. DBIC изолирует пользователя от фич БД в силу того что пытается
делать все "универсально", то есть расчитан на худшую из БД (один
populate чего стоит)

и соответственно получается из плюсов только:

1. вынос SQL-кода из проекта
2. благословление выборок в объекты

Соответственно я считаю что за нерешабельностью задачи составления
SQL-запроса от ее решения надо вообще отказываться (оставлять ее
человеку), соответственно давать ему возможность делать это удобно.

а-ля темплейты страниц в любом вебпроекте



From rabbit+moscowpm на rabbit.us  Thu Oct 27 13:13:58 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Thu, 27 Oct 2011 16:13:58 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111027200530.GP14585@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
Message-ID: <20111027201358.GB13125@rabbit.us>

On Fri, Oct 28, 2011 at 12:05:31AM +0400, Ivan Petrov wrote:
> 
> > По нескольку раз в год, в каком то углу интернета
> > поднимается вой что проект X тяжел, глуп, и вобще отстой.
> 
> я не говорил что DBIC глуп, тем паче что тяжел
> 
> я говорю:
> 
> 1. DBIC пытаются решить принципиально нерешаемую задачу (впрочем когда
> изобретут AI задача станет решаемой). В силу этого задачки чуть
> сложнее двух таблиц для него становятся трудноразрешимыми
> 2. DBIC изолирует пользователя от фич БД в силу того что пытается
> делать все "универсально", то есть расчитан на худшую из БД (один
> populate чего стоит)

А где пример?

> 
> и соответственно получается из плюсов только:
> 
> 1. вынос SQL-кода из проекта
> 2. благословление выборок в объекты
> 
> Соответственно я считаю что за нерешабельностью задачи составления
> SQL-запроса от ее решения надо вообще отказываться (оставлять ее
> человеку), соответственно давать ему возможность делать это удобно.

Я (ясен пень) совершенно не согласен с приговором "нерешабельности" :)
Снова прошу - приведи конкретный пример.

From zzz на zzz.org.ua  Thu Oct 27 13:18:40 2011
From: zzz на zzz.org.ua (Alexandr Gomoliako)
Date: Thu, 27 Oct 2011 23:18:40 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
	=?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <20111027200530.GP14585@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
Message-ID: <CAKb9G9ibHRbNqctcz_BAOSE1j6t5dHtV3E8kfbW3MG7PDvLdPA@mail.gmail.com>

> Соответственно я считаю что за нерешабельностью задачи составления
> SQL-запроса от ее решения надо вообще отказываться (оставлять ее
> человеку), соответственно давать ему возможность делать это удобно.
>
> а-ля темплейты страниц в любом вебпроекте

А-ля json http сервис, не обязательно даже RESTful. И никаких проблем.

GET /users/ivan.petrov

HTTP/1.0 200 OK
...
{
    "name": "Ivan Petrov",
    "age": ...
}

А внутри сервиса запросы через обычный DBI, а может когда-то
и его выкините и перейдете на что-то более быстрое, типа
dbslayer. Плюс сверху такого сервиса можно varnish ставить
или что-то такое и кэшировать любые ответы у которых
no-cache не установлен.

From rabbit+moscowpm на rabbit.us  Thu Oct 27 13:24:35 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Thu, 27 Oct 2011 16:24:35 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <CAKb9G9ibHRbNqctcz_BAOSE1j6t5dHtV3E8kfbW3MG7PDvLdPA@mail.gmail.com>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<CAKb9G9ibHRbNqctcz_BAOSE1j6t5dHtV3E8kfbW3MG7PDvLdPA@mail.gmail.com>
Message-ID: <20111027202435.GC13125@rabbit.us>

On Thu, Oct 27, 2011 at 11:18:40PM +0300, Alexandr Gomoliako wrote:
> > Соответственно я считаю что за нерешабельностью задачи составления
> > SQL-запроса от ее решения надо вообще отказываться (оставлять ее
> > человеку), соответственно давать ему возможность делать это удобно.
> >
> > а-ля темплейты страниц в любом вебпроекте
> 
> А-ля json http сервис, не обязательно даже RESTful. И никаких проблем.
> 
> GET /users/ivan.petrov
> 
> HTTP/1.0 200 OK
> ...
> {
>     "name": "Ivan Petrov",
>     "age": ...
> }
> 
> А внутри сервиса запросы через обычный DBI, а может когда-то
> и его выкините и перейдете на что-то более быстрое, типа
> dbslayer. Плюс сверху такого сервиса можно varnish ставить
> или что-то такое и кэшировать любые ответы у которых
> no-cache не установлен.

Для обслуживания таких запросов RDBMS вобще неуместен. Полно ведь non-SQL
решений для обслуживания именно таких "bag of data" ситуаций. Автор треда
недоволен как DBIC справляется с генерацией сложного *relational* SQL -
несколько таблиц и все такое. С чем я и спорю :)




From meettya на gmail.com  Thu Oct 27 13:25:50 2011
From: meettya на gmail.com (Dmitry Karpich)
Date: Fri, 28 Oct 2011 00:25:50 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <CAKb9G9ibHRbNqctcz_BAOSE1j6t5dHtV3E8kfbW3MG7PDvLdPA@mail.gmail.com>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<CAKb9G9ibHRbNqctcz_BAOSE1j6t5dHtV3E8kfbW3MG7PDvLdPA@mail.gmail.com>
Message-ID: <2B3B3FA3-6F16-4702-979F-28C7417EA355@gmail.com>


On Oct 28, 2011, at 12:18 AM, Alexandr Gomoliako wrote:

>> Соответственно я считаю что за нерешабельностью задачи составления
>> SQL-запроса от ее решения надо вообще отказываться (оставлять ее
>> человеку), соответственно давать ему возможность делать это удобно.
>> 
>> а-ля темплейты страниц в любом вебпроекте
> 
> А-ля json http сервис, не обязательно даже RESTful. И никаких проблем.
> 

ндаа... а сколько это будет "стоить"?
и "забудьте про агрегаты"?

нишевое решение

> GET /users/ivan.petrov
> 
> HTTP/1.0 200 OK
> ...
> {
>    "name": "Ivan Petrov",
>    "age": ...
> }
> 
> А внутри сервиса запросы через обычный DBI, а может когда-то
> и его выкините и перейдете на что-то более быстрое, типа
> dbslayer. Плюс сверху такого сервиса можно varnish ставить
> или что-то такое и кэшировать любые ответы у которых
> no-cache не установлен.
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org


From i.petro.77.00 на gmail.com  Thu Oct 27 13:32:58 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 00:32:58 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <20111027201358.GB13125@rabbit.us>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
Message-ID: <20111027203257.GD19081@apache.rbscorp.ru>


> Я (ясен пень) совершенно не согласен с приговором "нерешабельности" :)

если кто решит эту задачу я буду его решение везде рекламировть )

только я сомневаюсь что в обозримое будущее это произойдет.
Я тоже верю в человечество: рано или поздно оно изобретет AI. но это
не при нас произойдет. не при ныне живущих.

> Снова прошу - приведи конкретный пример.

да пример типичный для любого бизнеса

имеем группы пользователей
имеем задачи которые сваливаются на нескольких пользователей (может
свалиться на разных пользователей разных групп)
имеем индивидуальные статусы по каждой задаче у каждого пользователя
ну и этапы (подзадачи), которые сам пользователь может завести по
каждой задаче

надо вывести такой отчетик по группе пользователей:
задача - параметры задачи - достиг ли кто статуса XXX


соответственно таблицы
группы - пользователи - отношение
задачи - отношение к пользователям - статусы
этапы - отношение к задачам - статусы

DBIC тут такие ахтунги в SQL прорисовывал, что с этого и начали что
вернулись к SQL на котором написали один SELECT с одним GROUP BY и
двумя JOIN'ами.

у DBIC проблема в том что он пытается разные объекты выбрать в разные
столбики. из за этого и получается ужоснах.

ну уж не говоря о простом:

имеем объект

user

у него есть отношение

task


$user->task->delete;

далее
$user->is_changed == 0
$user->in_storage == 1

отношения между объектами, говорите? где они? 
ладно бы они были реализованы

From i.petro.77.00 на gmail.com  Thu Oct 27 13:16:08 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 00:16:08 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <1284952686.20111027193355@softsearch.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<CANVWn7EEjv7_OGN8FmXGb7hruq_R9LW+1iuOFPwNP7bNugKcuQ@mail.gmail.com>
	<20111026165318.GG14585@apache.rbscorp.ru>
	<CAFtO3fnXVoCUOcsHFPsXGAuB363S_C0PFaFLqOg8SYmppYOztg@mail.gmail.com>
	<20111026173155.GK14585@apache.rbscorp.ru>
	<1284952686.20111027193355@softsearch.ru>
Message-ID: <20111027201608.GC19081@apache.rbscorp.ru>


>> я думал с внедрением ORM у нас упростится работа с БД. в итоге она
>> усложнилась. я хочу ее все-таки упростить

> Знаете какая версия windows самая удобная? Та, в которой Вы работаете.

виндовс удобных версий нет вообще.

вот когда этот 10 гигабайтовый набор мусора сможет реализовать хоть
часть того функционала, который есть в 5-мегабайтовом awesome, скажем.
тогда я погляжу может на него :)

From i.petro.77.00 на gmail.com  Thu Oct 27 13:14:48 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 00:14:48 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <CANVWn7FtxENdU5g2it9hGCoqiHExFQa3WH0G+CbOkTrZvYGvmw@mail.gmail.com>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<CANVWn7EEjv7_OGN8FmXGb7hruq_R9LW+1iuOFPwNP7bNugKcuQ@mail.gmail.com>
	<20111026165318.GG14585@apache.rbscorp.ru>
	<CANVWn7Ey6nHo2P5_hpd3Vb6123pRrN4jrp3mR+HqmCW+nmspDw@mail.gmail.com>
	<20111026172855.GJ14585@apache.rbscorp.ru>
	<CANVWn7GZQPvBSnh6zYe7mJ07fU+ZEstN5YNtz6BhzXyFxyHqQw@mail.gmail.com>
	<20111027120009.GM14585@apache.rbscorp.ru>
	<CANVWn7FtxENdU5g2it9hGCoqiHExFQa3WH0G+CbOkTrZvYGvmw@mail.gmail.com>
Message-ID: <20111027201448.GB19081@apache.rbscorp.ru>


> Это неправда. Нормальный ORM возвращает итератор, а объекты создаёт только
> когда они действительно нужны.

это кстати несложно реализовать и в случае, если запросы человек
писать будет.


а насчет "нормальный ORM" покажите таковой, интересно.
ну бог с ними с запросами которые он криво составляет. покажите хотя
бы тот который будет скажем все варианты типов столбиков Pg
использовать. хотя-бы hstore в нем. ну а дальше поговорим про место
между клавиатурой и спикой кресла ;)


> ORM -- это Object-relational mapping, а не конструктор запросов.

дык я с того и начал. основная моя идея такая:
1. выкидываем нафиг конструктор запросов
2. даем возможность человеку их удобно конструировать самому (потому
что при пользовании ORM для человека это крайне труднодоступно)
3. даем возможность делать выборки в объекты, relational между
которыми и в случае DBIC и в любом другом случае делаются вручную,
посему автоматизация тут тоже нахрен не нужна.

на выходе получаем профит.

PS: собственно я зачем сюда писал, я пытался выяснить может кто делал
что подобное, а я велики тут городить взялся.
вопрос я свой выяснил. 

всем спасибо.

From i.petro.77.00 на gmail.com  Thu Oct 27 13:07:50 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 00:07:50 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <CAMOxC8sOVrpPBqEfTowv_5xz1WxV69-Z2MidcQjJgGiAq8Jn4A@mail.gmail.com>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<0BF3245D-1EAF-4B92-B002-6EF6EE15F81D@kostenko.name>
	<20111026172329.GH14585@apache.rbscorp.ru>
	<CAMOxC8sOVrpPBqEfTowv_5xz1WxV69-Z2MidcQjJgGiAq8Jn4A@mail.gmail.com>
Message-ID: <20111027200750.GA19081@apache.rbscorp.ru>

>> да по всякому пробовали
>> 
>>> 1. Нужно подменять storage, а не модель.
>> 
>> в этом случае ОЧЕНЬ сложные тесты получаются.
>> модель может экспортировать 2 функции. их подменить - в тесте написать
>> две функции.
>> в storage может оказаться что надо подменять 10-20 функций.

> Замечание только по тестированию. БД - ключевой элемент в вашем
> проекте. Так?

не только. просто получается куда ни кинь всюду клин.
профита я не вижу. профита от технологии



From rabbit+moscowpm на rabbit.us  Thu Oct 27 13:38:05 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Thu, 27 Oct 2011 16:38:05 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111027203257.GD19081@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
Message-ID: <20111027203805.GD13125@rabbit.us>

On Fri, Oct 28, 2011 at 12:32:58AM +0400, Ivan Petrov wrote:
> 
> > Я (ясен пень) совершенно не согласен с приговором "нерешабельности" :)
> 
> если кто решит эту задачу я буду его решение везде рекламировть )
> 
> только я сомневаюсь что в обозримое будущее это произойдет.
> Я тоже верю в человечество: рано или поздно оно изобретет AI. но это
> не при нас произойдет. не при ныне живущих.
> 
> > Снова прошу - приведи конкретный пример.
> 
> да пример типичный для любого бизнеса
> 
> имеем группы пользователей
> имеем задачи которые сваливаются на нескольких пользователей (может
> свалиться на разных пользователей разных групп)
> имеем индивидуальные статусы по каждой задаче у каждого пользователя
> ну и этапы (подзадачи), которые сам пользователь может завести по
> каждой задаче
> 
> надо вывести такой отчетик по группе пользователей:
> задача - параметры задачи - достиг ли кто статуса XXX
> 
> 
> соответственно таблицы
> группы - пользователи - отношение
> задачи - отношение к пользователям - статусы
> этапы - отношение к задачам - статусы
> 
> DBIC тут такие ахтунги в SQL прорисовывал, что с этого и начали что
> вернулись к SQL на котором написали один SELECT с одним GROUP BY и
> двумя JOIN'ами.
> 
> у DBIC проблема в том что он пытается разные объекты выбрать в разные
> столбики. из за этого и получается ужоснах.
> 

Я не том спрашивал :(

Как сказано в http://mail.pm.org/pipermail/moscow-pm/2011-October/010808.html
> Для начала - выложите search() с аргументами, и какой SQL был в результате
> наворочен. Для дополнительного бонуса - предложите каким SQL можно бы было
> все заменить

Все остальное пустой звук с извинением
.

From rabbit+moscowpm на rabbit.us  Thu Oct 27 13:38:50 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Thu, 27 Oct 2011 16:38:50 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <2B3B3FA3-6F16-4702-979F-28C7417EA355@gmail.com>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<CAKb9G9ibHRbNqctcz_BAOSE1j6t5dHtV3E8kfbW3MG7PDvLdPA@mail.gmail.com>
	<2B3B3FA3-6F16-4702-979F-28C7417EA355@gmail.com>
Message-ID: <20111027203849.GE13125@rabbit.us>

BOn Fri, Oct 28, 2011 at 12:25:50AM +0400, Dmitry Karpich wrote:
> 
> On Oct 28, 2011, at 12:18 AM, Alexandr Gomoliako wrote:
> 
> >> Соответственно я считаю что за нерешабельностью задачи составления
> >> SQL-запроса от ее решения надо вообще отказываться (оставлять ее
> >> человеку), соответственно давать ему возможность делать это удобно.
> >> 
> >> а-ля темплейты страниц в любом вебпроекте
> > 
> > А-ля json http сервис, не обязательно даже RESTful. И никаких проблем.
> > 
> 
> ндаа... а сколько это будет "стоить"?
> и "забудьте про агрегаты"?
> 

http://browsertoolkit.com/fault-tolerance.png

:)

From zzz на zzz.org.ua  Thu Oct 27 13:39:21 2011
From: zzz на zzz.org.ua (Alexandr Gomoliako)
Date: Thu, 27 Oct 2011 23:39:21 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
	=?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <2B3B3FA3-6F16-4702-979F-28C7417EA355@gmail.com>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<CAKb9G9ibHRbNqctcz_BAOSE1j6t5dHtV3E8kfbW3MG7PDvLdPA@mail.gmail.com>
	<2B3B3FA3-6F16-4702-979F-28C7417EA355@gmail.com>
Message-ID: <CAKb9G9g17s8q1DbxoRH808C3C0GN2bv7g5xG=6Lx6cU_u5oXCg@mail.gmail.com>

On Thu, Oct 27, 2011 at 11:25 PM, Dmitry Karpich <meettya на gmail.com> wrote:
>> А-ля json http сервис, не обязательно даже RESTful. И никаких проблем.

> ндаа... а сколько это будет "стоить"?
> и "забудьте про агрегаты"?

Стоить в каком смысле?
Разработка -- супер быстро, берете встроенный перл в nginx, JSON::XS
смотрите в $r->uri и генерите запросы к DBI, легко. К тому же ответы через
$r->print будут отсылаться асинхронно.
Производительность -- очень быстро, никто не забирает http keepalive,
плюс промежуточно кэшировать можно.

From meettya на gmail.com  Thu Oct 27 13:47:30 2011
From: meettya на gmail.com (Dmitry Karpich)
Date: Fri, 28 Oct 2011 00:47:30 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <20111027203849.GE13125@rabbit.us>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<CAKb9G9ibHRbNqctcz_BAOSE1j6t5dHtV3E8kfbW3MG7PDvLdPA@mail.gmail.com>
	<2B3B3FA3-6F16-4702-979F-28C7417EA355@gmail.com>
	<20111027203849.GE13125@rabbit.us>
Message-ID: <2B9B9844-7726-485E-A27A-D782717B1A99@gmail.com>


On Oct 28, 2011, at 12:38 AM, Peter Rabbitson wrote:

> BOn Fri, Oct 28, 2011 at 12:25:50AM +0400, Dmitry Karpich wrote:
>> 
>> On Oct 28, 2011, at 12:18 AM, Alexandr Gomoliako wrote:
>> 
>>>> Соответственно я считаю что за нерешабельностью задачи составления
>>>> SQL-запроса от ее решения надо вообще отказываться (оставлять ее
>>>> человеку), соответственно давать ему возможность делать это удобно.
>>>> 
>>>> а-ля темплейты страниц в любом вебпроекте
>>> 
>>> А-ля json http сервис, не обязательно даже RESTful. И никаких проблем.
>>> 
>> 
>> ндаа... а сколько это будет "стоить"?
>> и "забудьте про агрегаты"?
>> 
> 
> http://browsertoolkit.com/fault-tolerance.png
> 
> :)

:) оно слышало про NoSQL
периодически с ними возникают сложности, так что тоже не silver bullet ни разу.

> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org


From i.petro.77.00 на gmail.com  Thu Oct 27 13:49:42 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 00:49:42 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <20111027203805.GD13125@rabbit.us>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<20111027203805.GD13125@rabbit.us>
Message-ID: <20111027204942.GA20514@apache.rbscorp.ru>

> Я не том спрашивал :(

я тоже спрашивая надеялся получить ссылки на готовые проекты, а не
ответы вида "вы готовить DBIC не умеете".

> Как сказано в http://mail.pm.org/pipermail/moscow-pm/2011-October/010808.html
>> Для начала - выложите search() с аргументами, и какой SQL был в результате
>> наворочен. Для дополнительного бонуса - предложите каким SQL можно бы было
>> все заменить

> Все остальное пустой звук с извинением

я структуру таблиц и требуемый отчет по ним привел. по моему этого
достаточно.

From meettya на gmail.com  Thu Oct 27 13:50:33 2011
From: meettya на gmail.com (Dmitry Karpich)
Date: Fri, 28 Oct 2011 00:50:33 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <CAKb9G9g17s8q1DbxoRH808C3C0GN2bv7g5xG=6Lx6cU_u5oXCg@mail.gmail.com>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<CAKb9G9ibHRbNqctcz_BAOSE1j6t5dHtV3E8kfbW3MG7PDvLdPA@mail.gmail.com>
	<2B3B3FA3-6F16-4702-979F-28C7417EA355@gmail.com>
	<CAKb9G9g17s8q1DbxoRH808C3C0GN2bv7g5xG=6Lx6cU_u5oXCg@mail.gmail.com>
Message-ID: <B9EE3B8C-9839-4DE6-B9F0-300DBE35A5AB@gmail.com>


On Oct 28, 2011, at 12:39 AM, Alexandr Gomoliako wrote:

> On Thu, Oct 27, 2011 at 11:25 PM, Dmitry Karpich <meettya на gmail.com> wrote:
>>> А-ля json http сервис, не обязательно даже RESTful. И никаких проблем.
> 
>> ндаа... а сколько это будет "стоить"?
>> и "забудьте про агрегаты"?
> 
> Стоить в каком смысле?

"стоимость" - это классическое определение сложности запроса, explain его обычно рассказывает.

> Разработка -- супер быстро, берете встроенный перл в nginx, JSON::XS
> смотрите в $r->uri и генерите запросы к DBI, легко. К тому же ответы через
> $r->print будут отсылаться асинхронно.
> Производительность -- очень быстро, никто не забирает http keepalive,
> плюс промежуточно кэшировать можно.

лишнего удумали. Под такие задачи, как тут уже намекали старшие товарищи, есть NoSQL любого размера, сорта и цвета.
Они сами уже все умеют, знай только спрашивай.

> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org


From rabbit+moscowpm на rabbit.us  Thu Oct 27 13:55:54 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Thu, 27 Oct 2011 16:55:54 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111027204942.GA20514@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<20111027203805.GD13125@rabbit.us>
	<20111027204942.GA20514@apache.rbscorp.ru>
Message-ID: <20111027205554.GF13125@rabbit.us>

On Fri, Oct 28, 2011 at 12:49:42AM +0400, Ivan Petrov wrote:
> > Я не том спрашивал :(
> 
> я тоже спрашивая надеялся получить ссылки на готовые проекты, а не
> ответы вида "вы готовить DBIC не умеете".

А как я еще могу ответить на "не теряйте время на решение нерешимого",
особенно когда почти все уже решено? :)

> 
> > Как сказано в http://mail.pm.org/pipermail/moscow-pm/2011-October/010808.html
> >> Для начала - выложите search() с аргументами, и какой SQL был в результате
> >> наворочен. Для дополнительного бонуса - предложите каким SQL можно бы было
> >> все заменить
> 
> > Все остальное пустой звук с извинением
> 
> я структуру таблиц и требуемый отчет по ним привел. по моему этого
> достаточно.

Я могу привести наверное штук 6 *принципиально разных* раскладов таблиц
которые будут соответствовать данному отчету. Важно не что было спрошено
а *как* было сделано. Так как после трех запросов на елементарную копию
того ужаса о котором так много уже написано я ни фига не получил - я увы
самопосылаю себя на многобуквие.

Несмотря ни на что - если появятся реальные примеры, я всегда готов
разяснить и помоч. Удачи.



From zzz на zzz.org.ua  Thu Oct 27 13:57:40 2011
From: zzz на zzz.org.ua (Alexandr Gomoliako)
Date: Thu, 27 Oct 2011 23:57:40 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
	=?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <B9EE3B8C-9839-4DE6-B9F0-300DBE35A5AB@gmail.com>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<CAKb9G9ibHRbNqctcz_BAOSE1j6t5dHtV3E8kfbW3MG7PDvLdPA@mail.gmail.com>
	<2B3B3FA3-6F16-4702-979F-28C7417EA355@gmail.com>
	<CAKb9G9g17s8q1DbxoRH808C3C0GN2bv7g5xG=6Lx6cU_u5oXCg@mail.gmail.com>
	<B9EE3B8C-9839-4DE6-B9F0-300DBE35A5AB@gmail.com>
Message-ID: <CAKb9G9hjzYpsx1k6HMzqcZAEeRp1vi8BrHLOTbmvnJ+9wXAb4w@mail.gmail.com>

On Thu, Oct 27, 2011 at 11:50 PM, Dmitry Karpich <meettya на gmail.com> wrote:

> лишнего удумали. Под такие задачи, как тут уже намекали старшие товарищи, есть NoSQL любого размера, сорта и цвета.
> Они сами уже все умеют, знай только спрашивай.

Я говорил о JSON HTTP сервисе, как интерфейсе и почему это удобно.
А не о NoSQL.

From i.petro.77.00 на gmail.com  Thu Oct 27 14:01:54 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 01:01:54 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <20111027205554.GF13125@rabbit.us>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<20111027203805.GD13125@rabbit.us>
	<20111027204942.GA20514@apache.rbscorp.ru>
	<20111027205554.GF13125@rabbit.us>
Message-ID: <20111027210154.GB20514@apache.rbscorp.ru>

>> я тоже спрашивая надеялся получить ссылки на готовые проекты, а не
>> ответы вида "вы готовить DBIC не умеете".

> А как я еще могу ответить на "не теряйте время на решение нерешимого",
> особенно когда почти все уже решено? :)

покажите это "почти решено"

оно же даже отношение между ДВУМЯ объектами не умеет!


>> 
>>> Как сказано в http://mail.pm.org/pipermail/moscow-pm/2011-October/010808.html
>>>> Для начала - выложите search() с аргументами, и какой SQL был в результате
>>>> наворочен. Для дополнительного бонуса - предложите каким SQL можно бы было
>>>> все заменить
>> 
>>> Все остальное пустой звук с извинением
>> 
>> я структуру таблиц и требуемый отчет по ним привел. по моему этого
>> достаточно.

> Я могу привести наверное штук 6 *принципиально разных* раскладов таблиц
> которые будут соответствовать данному отчету. Важно не что было спрошено
> а *как* было сделано.

а оно делалось по всякому. нигде удобоваримого запроса не получилось.

тут проблема не в том *как*, а проблема в том что инструмент для таких
задач не подходит.
ну и 6 раскладов таблиц что вы приведете - ни один не даст нормального
SQL-запроса.
разве что провести полную денормализацию, либо делать VIEW на каждый
репорт. собственно и то и другое - решения из за ограниченности
инструмента

From rabbit+moscowpm на rabbit.us  Thu Oct 27 14:06:29 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Thu, 27 Oct 2011 17:06:29 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111027210154.GB20514@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<20111027203805.GD13125@rabbit.us>
	<20111027204942.GA20514@apache.rbscorp.ru>
	<20111027205554.GF13125@rabbit.us>
	<20111027210154.GB20514@apache.rbscorp.ru>
Message-ID: <20111027210629.GH13125@rabbit.us>

On Fri, Oct 28, 2011 at 01:01:54AM +0400, Ivan Petrov wrote:
> >> я тоже спрашивая надеялся получить ссылки на готовые проекты, а не
> >> ответы вида "вы готовить DBIC не умеете".
> 
> > А как я еще могу ответить на "не теряйте время на решение нерешимого",
> > особенно когда почти все уже решено? :)
> 
> покажите это "почти решено"
> 
> оно же даже отношение между ДВУМЯ объектами не умеет!
> 
> а оно делалось по всякому. нигде удобоваримого запроса не получилось.
> 

Хорошо... давай по другому: можно привести по крайней мере тото крайний
красивый и быстроваримый запрос запрос который ручками написали?

From andrei.protasovitski на gmail.com  Thu Oct 27 14:17:12 2011
From: andrei.protasovitski на gmail.com (Andrei)
Date: Thu, 27 Oct 2011 23:17:12 +0200
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111027201448.GB19081@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<CANVWn7EEjv7_OGN8FmXGb7hruq_R9LW+1iuOFPwNP7bNugKcuQ@mail.gmail.com>
	<20111026165318.GG14585@apache.rbscorp.ru>
	<CANVWn7Ey6nHo2P5_hpd3Vb6123pRrN4jrp3mR+HqmCW+nmspDw@mail.gmail.com>
	<20111026172855.GJ14585@apache.rbscorp.ru>
	<CANVWn7GZQPvBSnh6zYe7mJ07fU+ZEstN5YNtz6BhzXyFxyHqQw@mail.gmail.com>
	<20111027120009.GM14585@apache.rbscorp.ru>
	<CANVWn7FtxENdU5g2it9hGCoqiHExFQa3WH0G+CbOkTrZvYGvmw@mail.gmail.com>
	<20111027201448.GB19081@apache.rbscorp.ru>
Message-ID: <CANVWn7EZXqvNL=53h1OuC60Bzy6oW8M0dgG_VLyqduGrXTVZcA@mail.gmail.com>

27 октября 2011 г. 22:14 пользователь Ivan Petrov
<i.petro.77.00 на gmail.com>написал:

>
> > Это неправда. Нормальный ORM возвращает итератор, а объекты создаёт
> только
> > когда они действительно нужны.
>
> это кстати несложно реализовать и в случае, если запросы человек
> писать будет.
>
>
> а насчет "нормальный ORM" покажите таковой, интересно.
> ну бог с ними с запросами которые он криво составляет. покажите хотя
> бы тот который будет скажем все варианты типов столбиков Pg
> использовать. хотя-бы hstore в нем. ну а дальше поговорим про место
> между клавиатурой и спикой кресла ;)
>

Ваши "типы столбиков Pg" работают только в Pg. ORM призван абстрагировать
разработчика от всех этих тонкостей. Тем более что в больнитстве задач оно
нахрен не нужно.

> ORM -- это Object-relational mapping, а не конструктор запросов.
>
> дык я с того и начал. основная моя идея такая:
> 1. выкидываем нафиг конструктор запросов
>

Его не надо выкидывать, его просто можно не использовать.

2. даем возможность человеку их удобно конструировать самому (потому
> что при пользовании ORM для человека это крайне труднодоступно)
>

Вполне можно.


> 3. даем возможность делать выборки в объекты, relational между
> которыми и в случае DBIC и в любом другом случае делаются вручную,
> посему автоматизация тут тоже нахрен не нужна.
>

В ORM связи описываются вручную, это да. Но не "делаются вручную".


> на выходе получаем профит.
>

Профит должен быть измеряемым. Я с самого первого своего комментария прошу
результаты тестов для оценки профита, а в ответ получаю какую-то муть про
генератор запросов. В сравнении с выборкой данных генерирование запроса
такая мелочь, что на неё даже стыдно обращать внимание.


> PS: собственно я зачем сюда писал, я пытался выяснить может кто делал
> что подобное, а я велики тут городить взялся.
> вопрос я свой выяснил.
>

Я собственно, почему вопросы задаю. Я так и не понял, какую проблему решает
этот велосипед.

Я не зря написал, что после приведённого примера запроса дальнейший разговор
не имеет смысла. Тот запрос практически никогда не нужен. Более того, даже
если его разбить на несколько (сначала вынуть user'а, потом его роли, потом
что-то там ещё), потери в производительности практически не будет.


Если же нужны какие-то сводные таблицы, то ORM здесь не подходит. Сводными
таблицами и всякими другими отчётами занимаются специально обученные модули.



Ещё один немаловажный момент.

Написание собственного велосипеда это не только прикольно и интересно, но
ещё и грустно и скучно. Грустно, потому что его нужно поддерживать самому, а
это время и деньги. Скучно, потому что никто, кроме тебя о нём не знает,
коммьюнити никакое.

-- 
Andrei Protasovitski
< andrei[dot]protasovitski[at]gmail[dot]com >
Diemen, Netherlands
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111027/f810bb06/attachment.html>

From andrei.protasovitski на gmail.com  Thu Oct 27 14:22:14 2011
From: andrei.protasovitski на gmail.com (Andrei)
Date: Thu, 27 Oct 2011 23:22:14 +0200
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111027204942.GA20514@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<20111027203805.GD13125@rabbit.us>
	<20111027204942.GA20514@apache.rbscorp.ru>
Message-ID: <CANVWn7H+MHL=Qa+fJKe4BpRbijOYWTAvOp79V0csGpPjvNBtjw@mail.gmail.com>

27 октября 2011 г. 22:49 пользователь Ivan Petrov
<i.petro.77.00 на gmail.com>написал:

> > Я не том спрашивал :(
>
> я тоже спрашивая надеялся получить ссылки на готовые проекты, а не
> ответы вида "вы готовить DBIC не умеете".
>

Это потому что ваша проблема именно в неумении работать с ORM. Готовые
проекты едва ли существуют, потому что всех устраивают имеющиеся ORM.

> Как сказано в
> http://mail.pm.org/pipermail/moscow-pm/2011-October/010808.html
> >> Для начала - выложите search() с аргументами, и какой SQL был в
> результате
> >> наворочен. Для дополнительного бонуса - предложите каким SQL можно бы
> было
> >> все заменить
>
> > Все остальное пустой звук с извинением
>
> я структуру таблиц и требуемый отчет по ним привел. по моему этого
> достаточно.
>

Второй раз говорю: отчётами ORM не занимаются.

-- 
Andrei Protasovitski
< andrei[dot]protasovitski[at]gmail[dot]com >
Diemen, Netherlands
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111027/9631b292/attachment-0001.html>

From rabbit+moscowpm на rabbit.us  Thu Oct 27 14:25:15 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Thu, 27 Oct 2011 17:25:15 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <CANVWn7H+MHL=Qa+fJKe4BpRbijOYWTAvOp79V0csGpPjvNBtjw@mail.gmail.com>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<20111027203805.GD13125@rabbit.us>
	<20111027204942.GA20514@apache.rbscorp.ru>
	<CANVWn7H+MHL=Qa+fJKe4BpRbijOYWTAvOp79V0csGpPjvNBtjw@mail.gmail.com>
Message-ID: <20111027212515.GI13125@rabbit.us>

On Thu, Oct 27, 2011 at 11:22:14PM +0200, Andrei wrote:
> 27 октября 2011 г. 22:49 пользователь Ivan Petrov
> <i.petro.77.00 на gmail.com>написал:
> 
> > > Я не том спрашивал :(
> >
> > я тоже спрашивая надеялся получить ссылки на готовые проекты, а не
> > ответы вида "вы готовить DBIC не умеете".
> >
> 
> Это потому что ваша проблема именно в неумении работать с ORM. Готовые
> проекты едва ли существуют, потому что всех устраивают имеющиеся ORM.
> 
> > Как сказано в
> > http://mail.pm.org/pipermail/moscow-pm/2011-October/010808.html
> > >> Для начала - выложите search() с аргументами, и какой SQL был в
> > результате
> > >> наворочен. Для дополнительного бонуса - предложите каким SQL можно бы
> > было
> > >> все заменить
> >
> > > Все остальное пустой звук с извинением
> >
> > я структуру таблиц и требуемый отчет по ним привел. по моему этого
> > достаточно.
> >
> 
> Второй раз говорю: отчётами ORM не занимаются.
> 

Опять не правильно. Я лично например DBIC пользуюсь *исключиетльно* как
чертовски умным SQL генератором. Объекты почти не применяю, агрегации
почти везде, JOIN-ы тоже. Так что все зависит каким боок повернуть
инструмент. Но что тут поделаеш - народ решил что нельзя, значит нельзя.


From andrei.protasovitski на gmail.com  Thu Oct 27 14:28:49 2011
From: andrei.protasovitski на gmail.com (Andrei)
Date: Thu, 27 Oct 2011 23:28:49 +0200
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111027212515.GI13125@rabbit.us>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<20111027203805.GD13125@rabbit.us>
	<20111027204942.GA20514@apache.rbscorp.ru>
	<CANVWn7H+MHL=Qa+fJKe4BpRbijOYWTAvOp79V0csGpPjvNBtjw@mail.gmail.com>
	<20111027212515.GI13125@rabbit.us>
Message-ID: <CANVWn7HK+0SkXDZ-8UFWdCL98W2jwMMnLVtwOo0SEyM7SFS8Kw@mail.gmail.com>

27 октября 2011 г. 23:25 пользователь Peter Rabbitson <
rabbit+moscowpm на rabbit.us> написал:

>
> > Второй раз говорю: отчётами ORM не занимаются.
> >
>
> Опять не правильно. Я лично например DBIC пользуюсь *исключиетльно* как
> чертовски умным SQL генератором. Объекты почти не применяю, агрегации
> почти везде, JOIN-ы тоже. Так что все зависит каким боок повернуть
> инструмент. Но что тут поделаеш - народ решил что нельзя, значит нельзя.
>

Я не сказал, что это невозможно, или что так нельзя. Я сказал, что ORM для
этого не предназначен.

-- 
Andrei Protasovitski
< andrei[dot]protasovitski[at]gmail[dot]com >
Diemen, Netherlands
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111027/561fb657/attachment.html>

From andrei.protasovitski на gmail.com  Thu Oct 27 14:31:11 2011
From: andrei.protasovitski на gmail.com (Andrei)
Date: Thu, 27 Oct 2011 23:31:11 +0200
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111027203257.GD19081@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
Message-ID: <CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>

27 октября 2011 г. 22:32 пользователь Ivan Petrov
<i.petro.77.00 на gmail.com>написал:

> ну уж не говоря о простом:
>
> имеем объект
>
> user
>
> у него есть отношение
>
> task
>
>
> $user->task->delete;
>
> далее
> $user->is_changed == 0
> $user->in_storage == 1
>
> отношения между объектами, говорите? где они?
> ладно бы они были реализованы
>
>
Отношение здесь $user->task.

А какое поведение в этом случае ожидадлсь?

-- 
Andrei Protasovitski
< andrei[dot]protasovitski[at]gmail[dot]com >
Diemen, Netherlands
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111027/0524a186/attachment.html>

From rabbit+moscowpm на rabbit.us  Thu Oct 27 14:32:17 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Thu, 27 Oct 2011 17:32:17 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <CANVWn7HK+0SkXDZ-8UFWdCL98W2jwMMnLVtwOo0SEyM7SFS8Kw@mail.gmail.com>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<20111027203805.GD13125@rabbit.us>
	<20111027204942.GA20514@apache.rbscorp.ru>
	<CANVWn7H+MHL=Qa+fJKe4BpRbijOYWTAvOp79V0csGpPjvNBtjw@mail.gmail.com>
	<20111027212515.GI13125@rabbit.us>
	<CANVWn7HK+0SkXDZ-8UFWdCL98W2jwMMnLVtwOo0SEyM7SFS8Kw@mail.gmail.com>
Message-ID: <20111027213216.GJ13125@rabbit.us>

On Thu, Oct 27, 2011 at 11:28:49PM +0200, Andrei wrote:
> 27 октября 2011 г. 23:25 пользователь Peter Rabbitson <
> rabbit+moscowpm на rabbit.us> написал:
> 
> >
> > > Второй раз говорю: отчётами ORM не занимаются.
> > >
> >
> > Опять не правильно. Я лично например DBIC пользуюсь *исключиетльно* как
> > чертовски умным SQL генератором. Объекты почти не применяю, агрегации
> > почти везде, JOIN-ы тоже. Так что все зависит каким боок повернуть
> > инструмент. Но что тут поделаеш - народ решил что нельзя, значит нельзя.
> >
> 
> Я не сказал, что это невозможно, или что так нельзя. Я сказал, что ORM для
> этого не предназначен.
> 

На что я опять же отвечаю (как автор) - очень даже предназначен. Не надо
красить так густо :)

From andrei.protasovitski на gmail.com  Thu Oct 27 14:43:41 2011
From: andrei.protasovitski на gmail.com (Andrei)
Date: Thu, 27 Oct 2011 23:43:41 +0200
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111027213216.GJ13125@rabbit.us>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<20111027203805.GD13125@rabbit.us>
	<20111027204942.GA20514@apache.rbscorp.ru>
	<CANVWn7H+MHL=Qa+fJKe4BpRbijOYWTAvOp79V0csGpPjvNBtjw@mail.gmail.com>
	<20111027212515.GI13125@rabbit.us>
	<CANVWn7HK+0SkXDZ-8UFWdCL98W2jwMMnLVtwOo0SEyM7SFS8Kw@mail.gmail.com>
	<20111027213216.GJ13125@rabbit.us>
Message-ID: <CANVWn7Gji0S+_KqLdJrFvEHL83NNCFj_VSgSPTHcB==JiFiCow@mail.gmail.com>

27 октября 2011 г. 23:32 пользователь Peter Rabbitson <
rabbit+moscowpm на rabbit.us> написал:

> On Thu, Oct 27, 2011 at 11:28:49PM +0200, Andrei wrote:
> > 27 октября 2011 г. 23:25 пользователь Peter Rabbitson <
> > rabbit+moscowpm на rabbit.us> написал:
> >
> > >
> > > > Второй раз говорю: отчётами ORM не занимаются.
> > > >
> > >
> > > Опять не правильно. Я лично например DBIC пользуюсь *исключиетльно* как
> > > чертовски умным SQL генератором. Объекты почти не применяю, агрегации
> > > почти везде, JOIN-ы тоже. Так что все зависит каким боок повернуть
> > > инструмент. Но что тут поделаеш - народ решил что нельзя, значит
> нельзя.
> > >
> >
> > Я не сказал, что это невозможно, или что так нельзя. Я сказал, что ORM
> для
> > этого не предназначен.
> >
>
> На что я опять же отвечаю (как автор) - очень даже предназначен. Не надо
> красить так густо :)
>

Отвечаю как пользователь -- не предназначен. А на больших объёмах данных
даже вреден.

-- 
Andrei Protasovitski
< andrei[dot]protasovitski[at]gmail[dot]com >
Diemen, Netherlands
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111027/c9284ad0/attachment-0001.html>

From rabbit+moscowpm на rabbit.us  Thu Oct 27 15:31:10 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Thu, 27 Oct 2011 18:31:10 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <CANVWn7Gji0S+_KqLdJrFvEHL83NNCFj_VSgSPTHcB==JiFiCow@mail.gmail.com>
References: <20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<20111027203805.GD13125@rabbit.us>
	<20111027204942.GA20514@apache.rbscorp.ru>
	<CANVWn7H+MHL=Qa+fJKe4BpRbijOYWTAvOp79V0csGpPjvNBtjw@mail.gmail.com>
	<20111027212515.GI13125@rabbit.us>
	<CANVWn7HK+0SkXDZ-8UFWdCL98W2jwMMnLVtwOo0SEyM7SFS8Kw@mail.gmail.com>
	<20111027213216.GJ13125@rabbit.us>
	<CANVWn7Gji0S+_KqLdJrFvEHL83NNCFj_VSgSPTHcB==JiFiCow@mail.gmail.com>
Message-ID: <20111027223109.GK13125@rabbit.us>

On Thu, Oct 27, 2011 at 11:43:41PM +0200, Andrei wrote:
> 27 октября 2011 г. 23:32 пользователь Peter Rabbitson <
> rabbit+moscowpm на rabbit.us> написал:
> 
> > On Thu, Oct 27, 2011 at 11:28:49PM +0200, Andrei wrote:
> > > 27 октября 2011 г. 23:25 пользователь Peter Rabbitson <
> > > rabbit+moscowpm на rabbit.us> написал:
> > >
> > > >
> > > > > Второй раз говорю: отчётами ORM не занимаются.
> > > > >
> > > >
> > > > Опять не правильно. Я лично например DBIC пользуюсь *исключиетльно* как
> > > > чертовски умным SQL генератором. Объекты почти не применяю, агрегации
> > > > почти везде, JOIN-ы тоже. Так что все зависит каким боок повернуть
> > > > инструмент. Но что тут поделаеш - народ решил что нельзя, значит
> > нельзя.
> > > >
> > >
> > > Я не сказал, что это невозможно, или что так нельзя. Я сказал, что ORM
> > для
> > > этого не предназначен.
> > >
> >
> > На что я опять же отвечаю (как автор) - очень даже предназначен. Не надо
> > красить так густо :)
> >
> 
> Отвечаю как пользователь -- не предназначен. А на больших объёмах данных
> даже вреден.

Как решим вопрос? Предлагаю шпаги, пистолеты, или pastebin/gist/etc :)

From peter на vereshagin.org  Thu Oct 27 18:38:48 2011
From: peter на vereshagin.org (Peter Vereshagin)
Date: Fri, 28 Oct 2011 05:38:48 +0400
Subject: [Moscow.pm]
 =?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
 =?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <CAKb9G9g17s8q1DbxoRH808C3C0GN2bv7g5xG=6Lx6cU_u5oXCg@mail.gmail.com>
Message-ID: <20111028013848.GB8797@external.screwed.box>

Hello.

2011/10/27 13:39:23 -0700 moscow-pm-request на pm.org => To moscow-pm на pm.org :
> Разработка -- супер быстро, берете встроенный перл в nginx, JSON::XS
> смотрите в $r->uri и генерите запросы к DBI, легко. К тому же ответы через

это может быть рекомендовано?

Есть мнение что пока встроенный perl в nginx блокируется, например, ждёт ответа
из DBI, nginx хуже или вообще не отвечает остальным клиентам и т. о. perl
встроенный в nginx для такого в общем случае не предназначен.

--
Peter Vereshagin <peter на vereshagin.org> (http://vereshagin.org) pgp: A0E26627 

From peter на vereshagin.org  Thu Oct 27 19:00:25 2011
From: peter на vereshagin.org (Peter Vereshagin)
Date: Fri, 28 Oct 2011 06:00:25 +0400
Subject: [Moscow.pm]
 =?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
 =?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <CAGOcgF00x04Kr7-wn-5LeJXLKMkHQQU8q9GwOPqr0xc3wbFhMg@mail.gmail.com>
Message-ID: <20111028020023.GC8797@external.screwed.box>

Hello.

2011/10/26 23:07:13 -0700 moscow-pm-request на pm.org => To moscow-pm на pm.org :

> 2) любая публичная разработка начинается с GitHub, CPAN первое время точно
> не нужен.

сколько любителей GET-Хапчика. (=
А если кто Mercurial предпочитает?
когда github не нужен, бывает ещё PrePAN:

    http://blogs.perl.org/users/kentaro/2011/10/introducing-to-prepan.html

    PrePAN is a website for all Perl Mongers, especially for those  who have
    intention to upload their Perl modules to CPAN. PrePAN aims to be a good
    place for them to make discussion about Perl modules pre-uploaded to
    CPAN  (`PrePAN' is named after that).

по теме --- когда не хочу Moose, предпочитаю DBIC RDBO.
    
--
Peter Vereshagin <peter на vereshagin.org> (http://vereshagin.org) pgp: A0E26627 

From rabbit+moscowpm на rabbit.us  Thu Oct 27 19:05:33 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Thu, 27 Oct 2011 22:05:33 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111028020023.GC8797@external.screwed.box>
References: <CAGOcgF00x04Kr7-wn-5LeJXLKMkHQQU8q9GwOPqr0xc3wbFhMg@mail.gmail.com>
	<20111028020023.GC8797@external.screwed.box>
Message-ID: <20111028020533.GA24610@rabbit.us>

On Fri, Oct 28, 2011 at 06:00:25AM +0400, Peter Vereshagin wrote:
> Hello.
> 
> 2011/10/26 23:07:13 -0700 moscow-pm-request на pm.org => To moscow-pm на pm.org :
> 
> > 2) любая публичная разработка начинается с GitHub, CPAN первое время точно
> > не нужен.
> 
> сколько любителей GET-Хапчика. (=
> А если кто Mercurial предпочитает?
> когда github не нужен, бывает ещё PrePAN:
> 
>     http://blogs.perl.org/users/kentaro/2011/10/introducing-to-prepan.html
> 
>     PrePAN is a website for all Perl Mongers, especially for those  who have
>     intention to upload their Perl modules to CPAN. PrePAN aims to be a good
>     place for them to make discussion about Perl modules pre-uploaded to
>     CPAN  (`PrePAN' is named after that).
> 
> по теме --- когда не хочу Moose, предпочитаю DBIC RDBO.

А Moose каким боком связан с DBIC...?


From i.petro.77.00 на gmail.com  Thu Oct 27 23:20:06 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 10:20:06 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
Message-ID: <20111028062003.GC20514@apache.rbscorp.ru>

> ну уж не говоря о простом:

> имеем объект

> user

> у него есть отношение

> task

> $user->task->delete;

> далее
> $user->is_changed == 0
> $user->in_storage == 1

> отношения между объектами, говорите? где они?
> ладно бы они были реализованы

> Отношение здесь $user->task.

> А какое поведение в этом случае ожидадлсь?

не все БД поддерживают FOREIGN. соответственно ожидалось что при
удалении объекта отношения другой объект либо "молча" обновится (что
должно быть управляемо), либо будет помечен как измененный.

From i.petro.77.00 на gmail.com  Thu Oct 27 23:22:49 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 10:22:49 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <CANVWn7H+MHL=Qa+fJKe4BpRbijOYWTAvOp79V0csGpPjvNBtjw@mail.gmail.com>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<20111027203805.GD13125@rabbit.us>
	<20111027204942.GA20514@apache.rbscorp.ru>
	<CANVWn7H+MHL=Qa+fJKe4BpRbijOYWTAvOp79V0csGpPjvNBtjw@mail.gmail.com>
Message-ID: <20111028062248.GD20514@apache.rbscorp.ru>


> Это потому что ваша проблема именно в неумении работать с ORM. Готовые проекты
> едва ли существуют, потому что всех устраивают имеющиеся ORM.

тут, понимаешь ли, нужен микроскоп. а предлагаются линзы уровня
изготовления - времен Галилея. и при этом говорится "вы не умеете их
готовить".
нет пока технологий для изготовления микроскопов. потому для решения
насущных задач приходится использовать что-то другое.

>> Как сказано в http://mail.pm.org/pipermail/moscow-pm/2011-October/
> 010808.html
>>> Для начала - выложите search() с аргументами, и какой SQL был в
> результате
>>> наворочен. Для дополнительного бонуса - предложите каким SQL можно бы
> было
>>> все заменить

>> Все остальное пустой звук с извинением

> я структуру таблиц и требуемый отчет по ним привел. по моему этого
> достаточно.

> Второй раз говорю: отчётами ORM не занимаются.

второй раз говорю: прежде чем сделать отчет, необходимо сделать
выборку данных

From i.petro.77.00 на gmail.com  Thu Oct 27 23:30:05 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 10:30:05 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <CANVWn7EZXqvNL=53h1OuC60Bzy6oW8M0dgG_VLyqduGrXTVZcA@mail.gmail.com>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<CANVWn7EEjv7_OGN8FmXGb7hruq_R9LW+1iuOFPwNP7bNugKcuQ@mail.gmail.com>
	<20111026165318.GG14585@apache.rbscorp.ru>
	<CANVWn7Ey6nHo2P5_hpd3Vb6123pRrN4jrp3mR+HqmCW+nmspDw@mail.gmail.com>
	<20111026172855.GJ14585@apache.rbscorp.ru>
	<CANVWn7GZQPvBSnh6zYe7mJ07fU+ZEstN5YNtz6BhzXyFxyHqQw@mail.gmail.com>
	<20111027120009.GM14585@apache.rbscorp.ru>
	<CANVWn7FtxENdU5g2it9hGCoqiHExFQa3WH0G+CbOkTrZvYGvmw@mail.gmail.com>
	<20111027201448.GB19081@apache.rbscorp.ru>
	<CANVWn7EZXqvNL=53h1OuC60Bzy6oW8M0dgG_VLyqduGrXTVZcA@mail.gmail.com>
Message-ID: <20111028063004.GE20514@apache.rbscorp.ru>

> Ваши "типы столбиков Pg" работают только в Pg. ORM призван абстрагировать
> разработчика от всех этих тонкостей. Тем более что в больнитстве задач оно
> нахрен не нужно.

вот абстрагируя он мог бы дореализовывать отсутствующий в конкретной
БД функционал. но он пока не может реализовать простое отношение двух
объектов.

>> 1. выкидываем нафиг конструктор запросов

> Его не надо выкидывать, его просто можно не использовать.

ну дык вопрос в том что остается тогда?

> Я собственно, почему вопросы задаю. Я так и не понял, какую проблему решает
> этот велосипед.

описано в первом письме.


> Я не зря написал, что после приведённого примера запроса дальнейший разговор не
> имеет смысла. Тот запрос практически никогда не нужен. Более того, даже если
> его разбить на несколько (сначала вынуть user'а, потом его роли, потом что-то
> там ещё), потери в производительности практически не будет.

вот оно с DBIC всегда так. после того как ты подумал над задачей ты
пришел к тому что запрос разбить на несколько. и сам себя утешил
"потери производительности практически не будет"

потом смотришь лог запросов и он ужасен либо количеством либо
качеством


From isage на aumi.ru  Thu Oct 27 23:34:14 2011
From: isage на aumi.ru (iSage)
Date: Fri, 28 Oct 2011 09:34:14 +0300
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111028062003.GC20514@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
Message-ID: <05925c5fb76fa04ed78132478327b322@aumi.ru>

On Fri, 28 Oct 2011 10:20:06 +0400, Ivan Petrov
<i.petro.77.00 на gmail.com> wrote:
>> ну уж не говоря о простом:
>> имеем объект
>> user
>> у него есть отношение
>> task
>> $user->task->delete;
>> далее
>> $user->is_changed == 0
>> $user->in_storage == 1
>> отношения между объектами, говорите? где они?
>> ладно бы они были реализованы
>> Отношение здесь $user->task.
>> А какое поведение в этом случае ожидадлсь?
> 
> не все БД поддерживают FOREIGN. соответственно ожидалось что при
> удалении объекта отношения другой объект либо "молча" обновится (что
> должно быть управляемо), либо будет помечен как измененный.

У нас есть кошка и корм для нее. Кошка от него зависит. Корм кончился -
изменилась ли кошка?

From rabbit+moscowpm на rabbit.us  Thu Oct 27 23:46:40 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 02:46:40 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111028062003.GC20514@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
Message-ID: <20111028064640.GB24610@rabbit.us>


On Fri, Oct 28, 2011 at 10:20:06AM +0400, Ivan Petrov wrote:
> > ну уж не говоря о простом:
> 
> > имеем объект
> 
> > user
> 
> > у него есть отношение
> 
> > task
> 
> > $user->task->delete;
> 
> > далее
> > $user->is_changed == 0
> > $user->in_storage == 1
> 
> > отношения между объектами, говорите? где они?
> > ладно бы они были реализованы
> 
> > Отношение здесь $user->task.
> 
> > А какое поведение в этом случае ожидадлсь?
> 
> не все БД поддерживают FOREIGN. соответственно ожидалось что при
> удалении объекта отношения другой объект либо "молча" обновится (что
> должно быть управляемо), либо будет помечен как измененный.

А при чем здесь... Где в документации DBIC что либо сказано про synchronized
storage или даже про single instance storage? Я так понимаю такой код тебя
тоже смущает?

my $copy_one = $rs->first;
my $copy_two = $rs->first;

$copy_one->bar(500);
$copy_two->bar(600);

$copy_two->update;
$copy_one->update;

итог:

$copy_one->foo == 500
$copy_one->is_changed == 0

$copy_two->foo == 600
$copy_two->is_changed == 0

в СУБД - 500

Я еще в первом письме упомянул про недопонимание API. DBIC всего лиш
инструмент, не полный (говно)фреймворк. Вот напишем поверх него наш
(говно)фреймворк года через 2, с update scopes, single-instance-storage.
и т.д. - тогда милости просим опят попробовать, ибо то что мы имеем и чему
рады для тебя явно ORM не является.

From qalex на ashmanov.com  Fri Oct 28 00:03:24 2011
From: qalex на ashmanov.com (Alexander Q)
Date: Fri, 28 Oct 2011 11:03:24 +0400
Subject: [Moscow.pm]
 =?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
 =?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <20111028020023.GC8797@external.screwed.box>
References: <20111028020023.GC8797@external.screwed.box>
Message-ID: <4EAA53BC.5060202@ashmanov.com>

On 28.10.2011 06:00, Peter Vereshagin wrote:
>> 2) любая публичная разработка начинается с GitHub, CPAN первое время точно
>> не нужен.
> сколько любителей GET-Хапчика. (=
> А если кто Mercurial предпочитает?
>

bitbucket нонче и гит поддерживает, не только меркуриал. И репозитарии
закрытые даром в неограниченном количестве. Сплошной профит, ни одного
минуса.

-- 
Alexander Q                       mailto:qalex на ashmanov.com


From i.petro.77.00 на gmail.com  Fri Oct 28 00:03:53 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 11:03:53 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <20111028064640.GB24610@rabbit.us>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<20111028064640.GB24610@rabbit.us>
Message-ID: <20111028070352.GF20514@apache.rbscorp.ru>

>> не все БД поддерживают FOREIGN. соответственно ожидалось что при
>> удалении объекта отношения другой объект либо "молча" обновится (что
>> должно быть управляемо), либо будет помечен как измененный.

> А при чем здесь... Где в документации DBIC что либо сказано про synchronized
> storage или даже про single instance storage? Я так понимаю такой код тебя
> тоже смущает?

мне тут упирали на relational.

соответственно надо определиться где этот relational. только в БД?
тогда какой смысл его упоминать в отношении к ORM? или он и в
выбранных объектах тоже есть?

тогда почему при удалении этого самого relational-объекта, объекты к
которым это прямо относится ничего об этом "не знают" и "знать не
хотят"?


в нек. случаях интересно и наоборот

$user->delete чтобы удалял и $user->task.



From i.petro.77.00 на gmail.com  Fri Oct 28 00:07:33 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 11:07:33 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <05925c5fb76fa04ed78132478327b322@aumi.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<05925c5fb76fa04ed78132478327b322@aumi.ru>
Message-ID: <20111028070733.GG20514@apache.rbscorp.ru>

>> не все БД поддерживают FOREIGN. соответственно ожидалось что при
>> удалении объекта отношения другой объект либо "молча" обновится (что
>> должно быть управляемо), либо будет помечен как измененный.

> У нас есть кошка и корм для нее. Кошка от него зависит. Корм кончился -
> изменилась ли кошка?

именно!

From rabbit+moscowpm на rabbit.us  Fri Oct 28 00:12:48 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 03:12:48 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111028070352.GF20514@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<20111028064640.GB24610@rabbit.us>
	<20111028070352.GF20514@apache.rbscorp.ru>
Message-ID: <20111028071248.GC24610@rabbit.us>

On Fri, Oct 28, 2011 at 11:03:53AM +0400, Ivan Petrov wrote:
> >> не все БД поддерживают FOREIGN. соответственно ожидалось что при
> >> удалении объекта отношения другой объект либо "молча" обновится (что
> >> должно быть управляемо), либо будет помечен как измененный.
> 
> > А при чем здесь... Где в документации DBIC что либо сказано про synchronized
> > storage или даже про single instance storage? Я так понимаю такой код тебя
> > тоже смущает?
> 
> мне тут упирали на relational.
> 
> соответственно надо определиться где этот relational. только в БД?
> тогда какой смысл его упоминать в отношении к ORM? или он и в
> выбранных объектах тоже есть?

Relational в смысле с легкостью ходит по набору данных, не задолбывая
програмиста писать join-ы. Все происходит на уровне определения
resultset, что само по себе являтся "query-plan" (твой ненавистный
SQL генератор). После того как SQL забит в СУБД - данные можно заввернуть
в объекты а можно пользоватся так. По умолчанию объекты ничего друг о
друге больше не знают, и знать не должны.

> тогда почему при удалении этого самого relational-объекта, объекты к
> которым это прямо относится ничего об этом "не знают" и "знать не
> хотят"?

Потому что тогда нарушим правило "no single instance storage". То что я
показал в предыдущем письме не может сосуществовать с тем что ты хочеш.
Row обект не является 1) едиснтвенной копией на всю программу 2) не
гарантированно синхронизован с текущим состоянием СУБД.

Поверх можно конечно наворотить, но уже своими ручками. Есть кстати
http://search.cpan.org/~dcantrell/DBIx-Class-SingletonRows-0.11/lib/DBIx/Class/SingletonRows.pm


From i.petro.77.00 на gmail.com  Fri Oct 28 00:22:15 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 11:22:15 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <20111028071248.GC24610@rabbit.us>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<20111028064640.GB24610@rabbit.us>
	<20111028070352.GF20514@apache.rbscorp.ru>
	<20111028071248.GC24610@rabbit.us>
Message-ID: <20111028072215.GH20514@apache.rbscorp.ru>

> Потому что тогда нарушим правило "no single instance storage".

блин, ну я о том и говорю. что задача в современных условиях не
решаема. там нарушается одно правило, тут другое, а сям просто уровень
сложности большой.

соответственно отказываться надо от мусора и оставлять только то что
можно сделать.

From rabbit+moscowpm на rabbit.us  Fri Oct 28 00:30:55 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 03:30:55 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111028072215.GH20514@apache.rbscorp.ru>
References: <20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<20111028064640.GB24610@rabbit.us>
	<20111028070352.GF20514@apache.rbscorp.ru>
	<20111028071248.GC24610@rabbit.us>
	<20111028072215.GH20514@apache.rbscorp.ru>
Message-ID: <20111028073055.GD24610@rabbit.us>

BOn Fri, Oct 28, 2011 at 11:22:15AM +0400, Ivan Petrov wrote:
> > Потому что тогда нарушим правило "no single instance storage".
> 
> блин, ну я о том и говорю. что задача в современных условиях не
> решаема. там нарушается одно правило, тут другое, а сям просто уровень
> сложности большой.

Совсем бред какой то... проблема с генерацией кровожадного SQL (который
я так еще и не увидел) была нерешимой.

single-instance-storage 1) не фича DBIC 2) не фича без которой ORM уже
нелязя считат ORM.

> соответственно отказываться надо от мусора и оставлять только то что
> можно сделать.

По моему здесь проблема в том что ты от DBIC ожидаеш. Мне интересно знать
каким образом сложился данный набор фич которые никогда рядом не лежали,
ибо явно мне документацию править надо в стратегических местах.

В итоге (если есть еще интерес конечно) - давай определимся что сам DBIC
предоставляет, а что находится только и единственно у тебя в голове :)

Или как уже сказали раньше товарищи:
http://mail.pm.org/pipermail/moscow-pm/2011-October/010784.html

From mshogin на gmail.com  Fri Oct 28 00:53:12 2011
From: mshogin на gmail.com (=?KOI8-R?B?7cnIwcnMIPvPx8nO?=)
Date: Fri, 28 Oct 2011 11:53:12 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
	=?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <20111028072215.GH20514@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<20111028064640.GB24610@rabbit.us>
	<20111028070352.GF20514@apache.rbscorp.ru>
	<20111028071248.GC24610@rabbit.us>
	<20111028072215.GH20514@apache.rbscorp.ru>
Message-ID: <CALzA1My8HEzGXkOv5E_SJpvOpdDqu8dJCGyZTBrVBY3SuqDvyQ@mail.gmail.com>

Мда, долгая дискуссия.

ORM - зло!

Что такое SQL ( в простом определении ) - это то что мы хотим получить и
ПУТЬ получения данных.
При использовании ORM и конструкторов запросов, мы не черта не знаем каким
путем мы получаем данные, а это самое главное.
Как оптимизировать запросы? Как закреплять планы выполнения?
Ведь в каком то случае лучше использовать HASH JOIN, а в каком то NESTED
LOOP.

Даже банальная фильтрация данных может идти несколькими различными путями:
 - table full scan
 - index range scan + table access by rowid
 - index range scan
 - index full scan

Как всем этим управлять?


-- 
С уважением
Михаил Шогин.
Tel: +7 915 0311328
ICQ: 266776394
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/f04ad6ad/attachment.html>

From rabbit+moscowpm на rabbit.us  Fri Oct 28 00:57:15 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 03:57:15 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <CALzA1My8HEzGXkOv5E_SJpvOpdDqu8dJCGyZTBrVBY3SuqDvyQ@mail.gmail.com>
References: <20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<20111028064640.GB24610@rabbit.us>
	<20111028070352.GF20514@apache.rbscorp.ru>
	<20111028071248.GC24610@rabbit.us>
	<20111028072215.GH20514@apache.rbscorp.ru>
	<CALzA1My8HEzGXkOv5E_SJpvOpdDqu8dJCGyZTBrVBY3SuqDvyQ@mail.gmail.com>
Message-ID: <20111028075715.GE24610@rabbit.us>

On Fri, Oct 28, 2011 at 11:53:12AM +0400, Михаил Шогин wrote:
> Мда, долгая дискуссия.
> 
> ORM - зло!
> 
> Что такое SQL ( в простом определении ) - это то что мы хотим получить и
> ПУТЬ получения данных.
> При использовании ORM и конструкторов запросов, мы не черта не знаем каким
> путем мы получаем данные, а это самое главное.
> Как оптимизировать запросы? Как закреплять планы выполнения?
> Ведь в каком то случае лучше использовать HASH JOIN, а в каком то NESTED
> LOOP.
> 
> Даже банальная фильтрация данных может идти несколькими различными путями:
>  - table full scan
>  - index range scan + table access by rowid
>  - index range scan
>  - index full scan
> 
> Как всем этим управлять?

Фишка здесь в том что такой микроскоп нужен на 1 из 100 запросов. Хватай
голый $dbh из DBIC и делай что хочеш. Ведь нигде не сказано что раз DBIC
так всегда DBIC. Надо все таки уметь сообразить когда пора положить молоток
и взять отвертку :)

From mshogin на gmail.com  Fri Oct 28 01:09:42 2011
From: mshogin на gmail.com (=?KOI8-R?B?7cnIwcnMIPvPx8nO?=)
Date: Fri, 28 Oct 2011 12:09:42 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
	=?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <20111028075715.GE24610@rabbit.us>
References: <20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<20111028064640.GB24610@rabbit.us>
	<20111028070352.GF20514@apache.rbscorp.ru>
	<20111028071248.GC24610@rabbit.us>
	<20111028072215.GH20514@apache.rbscorp.ru>
	<CALzA1My8HEzGXkOv5E_SJpvOpdDqu8dJCGyZTBrVBY3SuqDvyQ@mail.gmail.com>
	<20111028075715.GE24610@rabbit.us>
Message-ID: <CALzA1Mz+zZccQ5qzM=_W+j8KWGa=REfLw6qbG5abaViv5H=0Kg@mail.gmail.com>

>
> > Мда, долгая дискуссия.
> >
> > ORM - зло!
> >
> > Что такое SQL ( в простом определении ) - это то что мы хотим получить и
> > ПУТЬ получения данных.
> > При использовании ORM и конструкторов запросов, мы не черта не знаем
> каким
> > путем мы получаем данные, а это самое главное.
> > Как оптимизировать запросы? Как закреплять планы выполнения?
> > Ведь в каком то случае лучше использовать HASH JOIN, а в каком то NESTED
> > LOOP.
> >
> > Даже банальная фильтрация данных может идти несколькими различными
> путями:
> >  - table full scan
> >  - index range scan + table access by rowid
> >  - index range scan
> >  - index full scan
> >
> > Как всем этим управлять?
>
> Фишка здесь в том что такой микроскоп нужен на 1 из 100 запросов. Хватай
> голый $dbh из DBIC и делай что хочеш. Ведь нигде не сказано что раз DBIC
> так всегда DBIC. Надо все таки уметь сообразить когда пора положить молоток
> и взять отвертку :)
>

Хех, нет, у нас не так. Запросы оптимизируются перед использованием в коде.
+ выставляются хинты для быстрого выявления тормозных запросов.



-- 
С уважением
Михаил Шогин.
Tel: +7 915 0311328
ICQ: 266776394
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/212c2988/attachment.html>

From rabbit+moscowpm на rabbit.us  Fri Oct 28 01:18:12 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 04:18:12 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <CALzA1Mz+zZccQ5qzM=_W+j8KWGa=REfLw6qbG5abaViv5H=0Kg@mail.gmail.com>
References: <20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<20111028064640.GB24610@rabbit.us>
	<20111028070352.GF20514@apache.rbscorp.ru>
	<20111028071248.GC24610@rabbit.us>
	<20111028072215.GH20514@apache.rbscorp.ru>
	<CALzA1My8HEzGXkOv5E_SJpvOpdDqu8dJCGyZTBrVBY3SuqDvyQ@mail.gmail.com>
	<20111028075715.GE24610@rabbit.us>
	<CALzA1Mz+zZccQ5qzM=_W+j8KWGa=REfLw6qbG5abaViv5H=0Kg@mail.gmail.com>
Message-ID: <20111028081811.GF24610@rabbit.us>

On Fri, Oct 28, 2011 at 12:09:42PM +0400, Михаил Шогин wrote:
> >
> > > Мда, долгая дискуссия.
> > >
> > > ORM - зло!
> > >
> > > Что такое SQL ( в простом определении ) - это то что мы хотим получить и
> > > ПУТЬ получения данных.
> > > При использовании ORM и конструкторов запросов, мы не черта не знаем
> > каким
> > > путем мы получаем данные, а это самое главное.
> > > Как оптимизировать запросы? Как закреплять планы выполнения?
> > > Ведь в каком то случае лучше использовать HASH JOIN, а в каком то NESTED
> > > LOOP.
> > >
> > > Даже банальная фильтрация данных может идти несколькими различными
> > путями:
> > >  - table full scan
> > >  - index range scan + table access by rowid
> > >  - index range scan
> > >  - index full scan
> > >
> > > Как всем этим управлять?
> >
> > Фишка здесь в том что такой микроскоп нужен на 1 из 100 запросов. Хватай
> > голый $dbh из DBIC и делай что хочеш. Ведь нигде не сказано что раз DBIC
> > так всегда DBIC. Надо все таки уметь сообразить когда пора положить молоток
> > и взять отвертку :)
> >
> 
> Хех, нет, у нас не так. Запросы оптимизируются перед использованием в коде.
> + выставляются хинты для быстрого выявления тормозных запросов.

Хех, ну если для вашей конторы такой уровен premature optimisation привидно
оптавдан (ибо никогда не может быть *реально* оправдан) - то с DBIC, да и
вообще любым генератором вам не по пути :)


From mshogin на gmail.com  Fri Oct 28 02:01:13 2011
From: mshogin на gmail.com (=?KOI8-R?B?7cnIwcnMIPvPx8nO?=)
Date: Fri, 28 Oct 2011 13:01:13 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
	=?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <20111028081811.GF24610@rabbit.us>
References: <20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<20111028064640.GB24610@rabbit.us>
	<20111028070352.GF20514@apache.rbscorp.ru>
	<20111028071248.GC24610@rabbit.us>
	<20111028072215.GH20514@apache.rbscorp.ru>
	<CALzA1My8HEzGXkOv5E_SJpvOpdDqu8dJCGyZTBrVBY3SuqDvyQ@mail.gmail.com>
	<20111028075715.GE24610@rabbit.us>
	<CALzA1Mz+zZccQ5qzM=_W+j8KWGa=REfLw6qbG5abaViv5H=0Kg@mail.gmail.com>
	<20111028081811.GF24610@rabbit.us>
Message-ID: <CALzA1MwHRLh2zQ5N2kPHaPhanidpt0i2i_-bFNR4YVxtj_2C8A@mail.gmail.com>

>
> On Fri, Oct 28, 2011 at 12:09:42PM +0400, Михаил Шогин wrote:
> > >
> > > > Мда, долгая дискуссия.
> > > >
> > > > ORM - зло!
> > > >
> > > > Что такое SQL ( в простом определении ) - это то что мы хотим
> получить и
> > > > ПУТЬ получения данных.
> > > > При использовании ORM и конструкторов запросов, мы не черта не знаем
> > > каким
> > > > путем мы получаем данные, а это самое главное.
> > > > Как оптимизировать запросы? Как закреплять планы выполнения?
> > > > Ведь в каком то случае лучше использовать HASH JOIN, а в каком то
> NESTED
> > > > LOOP.
> > > >
> > > > Даже банальная фильтрация данных может идти несколькими различными
> > > путями:
> > > >  - table full scan
> > > >  - index range scan + table access by rowid
> > > >  - index range scan
> > > >  - index full scan
> > > >
> > > > Как всем этим управлять?
> > >
> > > Фишка здесь в том что такой микроскоп нужен на 1 из 100 запросов.
> Хватай
> > > голый $dbh из DBIC и делай что хочеш. Ведь нигде не сказано что раз
> DBIC
> > > так всегда DBIC. Надо все таки уметь сообразить когда пора положить
> молоток
> > > и взять отвертку :)
> > >
> >
> > Хех, нет, у нас не так. Запросы оптимизируются перед использованием в
> коде.
> > + выставляются хинты для быстрого выявления тормозных запросов.
>
> Хех, ну если для вашей конторы такой уровен premature optimisation привидно
> оптавдан (ибо никогда не может быть *реально* оправдан) - то с DBIC, да и
> вообще любым генератором вам не по пути :)
>
Оптимизация становится хорошей привычкой и выполняется как часть процесса ;)

Точно так же как и в тестировании есть хороший паттерн
Red - Green - Refactor

имеем и применительно к SQL
SQL - Explain - Optimisation

Конечно генераторы пробовали, но поддержка, понимаемость кода падает прямо
пропорционально объему последнего.
Но надо сказать, что все это хорошо в случае жестких стандартов оформления
Perl, SQL и т.п.
В этом случае читаешь чужой код ка свой собственный

-- 
С уважением
Михаил Шогин.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/63c99326/attachment.html>

From andrei.protasovitski на gmail.com  Fri Oct 28 02:55:57 2011
From: andrei.protasovitski на gmail.com (Andrei)
Date: Fri, 28 Oct 2011 11:55:57 +0200
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111028070733.GG20514@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
Message-ID: <CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>

28 октября 2011 г. 9:07 пользователь Ivan Petrov
<i.petro.77.00 на gmail.com>написал:

> >> не все БД поддерживают FOREIGN. соответственно ожидалось что при
> >> удалении объекта отношения другой объект либо "молча" обновится (что
> >> должно быть управляемо), либо будет помечен как измененный.
>
> > У нас есть кошка и корм для нее. Кошка от него зависит. Корм кончился -
> > изменилась ли кошка?
>
> именно!
>

Хорошо, раз вы не знаете ответа, то я отвечу: кошка не изменилась.

Вообще неплохо бы научиться понимать, что, с чем и как связано. В случае
пользователь-задача нужно чётко осознавать, что пользователь суть свойство
задачи, а не наоборот. Если задача была переассаёнена на другого
пользователя, мы меняем одну задачу, а не двух пользователей. С кошкой то же
самое. Если её корм отдать собаке, то мы меняем положение тарелки с кормом,
а не кошки с собакой.

-- 
Andrei Protasovitski
< andrei[dot]protasovitski[at]gmail[dot]com >
Diemen, Netherlands
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/37619230/attachment.html>

From i.petro.77.00 на gmail.com  Fri Oct 28 01:56:25 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 12:56:25 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <20111028081811.GF24610@rabbit.us>
References: <CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<20111028064640.GB24610@rabbit.us>
	<20111028070352.GF20514@apache.rbscorp.ru>
	<20111028071248.GC24610@rabbit.us>
	<20111028072215.GH20514@apache.rbscorp.ru>
	<CALzA1My8HEzGXkOv5E_SJpvOpdDqu8dJCGyZTBrVBY3SuqDvyQ@mail.gmail.com>
	<20111028075715.GE24610@rabbit.us>
	<CALzA1Mz+zZccQ5qzM=_W+j8KWGa=REfLw6qbG5abaViv5H=0Kg@mail.gmail.com>
	<20111028081811.GF24610@rabbit.us>
Message-ID: <20111028085625.GJ20514@apache.rbscorp.ru>

>> Хех, нет, у нас не так. Запросы оптимизируются перед использованием в коде.
>> + выставляются хинты для быстрого выявления тормозных запросов.

> Хех, ну если для вашей конторы такой уровен premature optimisation привидно
> оптавдан (ибо никогда не может быть *реально* оправдан) - то с DBIC, да и
> вообще любым генератором вам не по пути :)

это потому что нормальный генератор запросов в современных условиях
(отстутсует AI) сделать невозможно.

From i.petro.77.00 на gmail.com  Fri Oct 28 02:02:10 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 13:02:10 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
Message-ID: <20111028090209.GK20514@apache.rbscorp.ru>

В продолжение к теме про ORM.

Ребят, если у вас все так клево получается и запросы сами
генерируются, качественно.
то может вы напишите автогенератор сайтов?

что нафиг все вебразработчики трахаются, темплейты какие-то.
ну их нафиг!

давайте сделайте автогенерацию, пусть они только опишут в виде
хешей что им надо, передадут эти хеши вашей функции и вы им сайт с уже
готовыми текстами, формами итп выдадите.

это ж клондайк! и главное (по вашему) реализуемо!

;) <- смайлик тут

From yu.pats на gmail.com  Fri Oct 28 03:08:35 2011
From: yu.pats на gmail.com (Yury Pats)
Date: Fri, 28 Oct 2011 13:08:35 +0300
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <20111028090209.GK20514@apache.rbscorp.ru>
References: <20111028090209.GK20514@apache.rbscorp.ru>
Message-ID: <CAFtO3fn3n0VeaTh8NtOyYpyiJQeeiVxO9OKBNbV=bhCcSXe7Kw@mail.gmail.com>

А что рельсы отменили?

2011/10/28 Ivan Petrov <i.petro.77.00 на gmail.com>:
> В продолжение к теме про ORM.
>
> Ребят, если у вас все так клево получается и запросы сами
> генерируются, качественно.
> то может вы напишите автогенератор сайтов?
>
> что нафиг все вебразработчики трахаются, темплейты какие-то.
> ну их нафиг!
>
> давайте сделайте автогенерацию, пусть они только опишут в виде
> хешей что им надо, передадут эти хеши вашей функции и вы им сайт с уже
> готовыми текстами, формами итп выдадите.
>
> это ж клондайк! и главное (по вашему) реализуемо!
>
> ;) <- смайлик тут
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
WBR, Yury Pats
skype: yuripats
cellular: +375 (29) 5870723

From yu.pats на gmail.com  Fri Oct 28 03:08:58 2011
From: yu.pats на gmail.com (Yury Pats)
Date: Fri, 28 Oct 2011 13:08:58 +0300
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <CAFtO3fn3n0VeaTh8NtOyYpyiJQeeiVxO9OKBNbV=bhCcSXe7Kw@mail.gmail.com>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<CAFtO3fn3n0VeaTh8NtOyYpyiJQeeiVxO9OKBNbV=bhCcSXe7Kw@mail.gmail.com>
Message-ID: <CAFtO3f=Dwh-DUE3TOU1sbkMzTDGCqeRKUEMGdwrWknKgLde6bg@mail.gmail.com>

Вдогонку пару запятых: ,,,,,

2011/10/28 Yury Pats <yu.pats на gmail.com>:
> А что рельсы отменили?
>
> 2011/10/28 Ivan Petrov <i.petro.77.00 на gmail.com>:
>> В продолжение к теме про ORM.
>>
>> Ребят, если у вас все так клево получается и запросы сами
>> генерируются, качественно.
>> то может вы напишите автогенератор сайтов?
>>
>> что нафиг все вебразработчики трахаются, темплейты какие-то.
>> ну их нафиг!
>>
>> давайте сделайте автогенерацию, пусть они только опишут в виде
>> хешей что им надо, передадут эти хеши вашей функции и вы им сайт с уже
>> готовыми текстами, формами итп выдадите.
>>
>> это ж клондайк! и главное (по вашему) реализуемо!
>>
>> ;) <- смайлик тут
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>
>
>
>
> --
> WBR, Yury Pats
> skype: yuripats
> cellular: +375 (29) 5870723
>



-- 
WBR, Yury Pats
skype: yuripats
cellular: +375 (29) 5870723

From rabbit+moscowpm на rabbit.us  Fri Oct 28 03:10:00 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 06:10:00 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111028085625.GJ20514@apache.rbscorp.ru>
References: <20111028062003.GC20514@apache.rbscorp.ru>
	<20111028064640.GB24610@rabbit.us>
	<20111028070352.GF20514@apache.rbscorp.ru>
	<20111028071248.GC24610@rabbit.us>
	<20111028072215.GH20514@apache.rbscorp.ru>
	<CALzA1My8HEzGXkOv5E_SJpvOpdDqu8dJCGyZTBrVBY3SuqDvyQ@mail.gmail.com>
	<20111028075715.GE24610@rabbit.us>
	<CALzA1Mz+zZccQ5qzM=_W+j8KWGa=REfLw6qbG5abaViv5H=0Kg@mail.gmail.com>
	<20111028081811.GF24610@rabbit.us>
	<20111028085625.GJ20514@apache.rbscorp.ru>
Message-ID: <20111028101000.GJ24610@rabbit.us>

On Fri, Oct 28, 2011 at 12:56:25PM +0400, Ivan Petrov wrote:
> >> Хех, нет, у нас не так. Запросы оптимизируются перед использованием в коде.
> >> + выставляются хинты для быстрого выявления тормозных запросов.
> 
> > Хех, ну если для вашей конторы такой уровен premature optimisation привидно
> > оптавдан (ибо никогда не может быть *реально* оправдан) - то с DBIC, да и
> > вообще любым генератором вам не по пути :)
> 
> это потому что нормальный генератор запросов в современных условиях
> (отстутсует AI) сделать невозможно.

Прошло часов 15 с тех пор как я подключился - еще не одного примера где
SQL генератор сделал что либо не так. Про unrelated related objects мы уже
вроде все сказали, давай займемся сутью вопроса :)


From mshogin на gmail.com  Fri Oct 28 03:13:45 2011
From: mshogin на gmail.com (=?KOI8-R?B?7cnIwcnMIPvPx8nO?=)
Date: Fri, 28 Oct 2011 14:13:45 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBIVE1MIMkg18/P?=
	=?koi8-r?b?wt3F?=
In-Reply-To: <CAFtO3f=Dwh-DUE3TOU1sbkMzTDGCqeRKUEMGdwrWknKgLde6bg@mail.gmail.com>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<CAFtO3fn3n0VeaTh8NtOyYpyiJQeeiVxO9OKBNbV=bhCcSXe7Kw@mail.gmail.com>
	<CAFtO3f=Dwh-DUE3TOU1sbkMzTDGCqeRKUEMGdwrWknKgLde6bg@mail.gmail.com>
Message-ID: <CALzA1Mws2h6_Krc58KAcHQCo+fXr-Xxb5qb+oO+ovc=JvkV+bA@mail.gmail.com>

>
> > 2011/10/28 Ivan Petrov <i.petro.77.00 на gmail.com>:
> >> В продолжение к теме про ORM.
> >>
> >> Ребят, если у вас все так клево получается и запросы сами
> >> генерируются, качественно.
> >> то может вы напишите автогенератор сайтов?
> >>
> >> что нафиг все вебразработчики трахаются, темплейты какие-то.
> >> ну их нафиг!
> >>
> >> давайте сделайте автогенерацию, пусть они только опишут в виде
> >> хешей что им надо, передадут эти хеши вашей функции и вы им сайт с уже
> >> готовыми текстами, формами итп выдадите.
>

Вот это правильно.
Даешь программистам технических верстальщиков повсеместно!

( у нас есть такие команды, только данные отдают, шаблонами, в полном
объеме, верстальщики занимаются. )



> >>
> >> это ж клондайк! и главное (по вашему) реализуемо!
> >>
> >> ;) <- смайлик тут
> >> --
> >> Moscow.pm mailing list
> >> moscow-pm на pm.org | http://moscow.pm.org
> >>
> >
> >
> >
> > --
> > WBR, Yury Pats
> > skype: yuripats
> > cellular: +375 (29) 5870723
> >
>
>
>
> --
> WBR, Yury Pats
> skype: yuripats
> cellular: +375 (29) 5870723
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
С уважением
Михаил Шогин.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/6a889ebf/attachment.html>

From rabbit+moscowpm на rabbit.us  Fri Oct 28 03:15:33 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 06:15:33 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <20111028090209.GK20514@apache.rbscorp.ru>
References: <20111028090209.GK20514@apache.rbscorp.ru>
Message-ID: <20111028101532.GK24610@rabbit.us>

On Fri, Oct 28, 2011 at 01:02:10PM +0400, Ivan Petrov wrote:
> В продолжение к теме про ORM.
> 
> Ребят, если у вас все так клево получается и запросы сами
> генерируются, качественно.
> то может вы напишите автогенератор сайтов?
> 
> что нафиг все вебразработчики трахаются, темплейты какие-то.
> ну их нафиг!
> 
> давайте сделайте автогенерацию, пусть они только опишут в виде
> хешей что им надо, передадут эти хеши вашей функции и вы им сайт с уже
> готовыми текстами, формами итп выдадите.
> 
> это ж клондайк! и главное (по вашему) реализуемо!

В принципе Reaction прототип как раз такого чуда-юда. К сожалению работа
там затихла, ибо не получилось доковырять API чтоб тупому программеру
можно было разобратся. Что приводит меня к следующему:

Хороший фреймворк не тото который "все сам автогенерит", а который
правильно и без запинок транслирует более высокий API на более ниский.
Совершенно не значит что если "надо только хеши писать" не нужны
разработчики. Надо ведь чтоб кто-то те самые хеши с умом написал.

Твой аргумент какой то дикий - разница м/у DBIC и писать ручками SQL
подобна той между Perl и писать ручками assembler. Тебе Perl часом не
мешает?





From rabbit+moscowpm на rabbit.us  Fri Oct 28 03:19:44 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 06:19:44 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <20111028101532.GK24610@rabbit.us>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
Message-ID: <20111028101944.GM24610@rabbit.us>

On Fri, Oct 28, 2011 at 06:15:33AM -0400, Peter Rabbitson wrote:
> В принципе Reaction прототип как раз такого чуда-юда. К сожалению работа

Фу! Линк забыл: http://search.cpan.org/dist/Reaction

From yu.pats на gmail.com  Fri Oct 28 03:19:43 2011
From: yu.pats на gmail.com (Yury Pats)
Date: Fri, 28 Oct 2011 13:19:43 +0300
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <CALzA1Mws2h6_Krc58KAcHQCo+fXr-Xxb5qb+oO+ovc=JvkV+bA@mail.gmail.com>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<CAFtO3fn3n0VeaTh8NtOyYpyiJQeeiVxO9OKBNbV=bhCcSXe7Kw@mail.gmail.com>
	<CAFtO3f=Dwh-DUE3TOU1sbkMzTDGCqeRKUEMGdwrWknKgLde6bg@mail.gmail.com>
	<CALzA1Mws2h6_Krc58KAcHQCo+fXr-Xxb5qb+oO+ovc=JvkV+bA@mail.gmail.com>
Message-ID: <CAFtO3f=XMVOQxG9JDbzhN8hAuyd27pnUrDTNG6KtDZEA-myCRw@mail.gmail.com>

2011/10/28 Михаил Шогин <mshogin на gmail.com>:
>> > 2011/10/28 Ivan Petrov <i.petro.77.00 на gmail.com>:
>> >> В продолжение к теме про ORM.
>> >>
>> >> Ребят, если у вас все так клево получается и запросы сами
>> >> генерируются, качественно.
>> >> то может вы напишите автогенератор сайтов?
>> >>
>> >> что нафиг все вебразработчики трахаются, темплейты какие-то.
>> >> ну их нафиг!
>> >>
>> >> давайте сделайте автогенерацию, пусть они только опишут в виде
>> >> хешей что им надо, передадут эти хеши вашей функции и вы им сайт с уже
>> >> готовыми текстами, формами итп выдадите.
>
> Вот это правильно.
> Даешь программистам технических верстальщиков повсеместно!
> ( у нас есть такие команды, только данные отдают, шаблонами, в полном
> объеме, верстальщики занимаются. )
>

Это называется front-end разработчик. Днем с огнем не сыщешь.

>>
>> >>
>> >> это ж клондайк! и главное (по вашему) реализуемо!
>> >>
>> >> ;) <- смайлик тут
>> >> --
>> >> Moscow.pm mailing list
>> >> moscow-pm на pm.org | http://moscow.pm.org
>> >>
>> >
>> >
>> >
>> > --
>> > WBR, Yury Pats
>> > skype: yuripats
>> > cellular: +375 (29) 5870723
>> >
>>
>>
>>
>> --
>> WBR, Yury Pats
>> skype: yuripats
>> cellular: +375 (29) 5870723
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>
>
>
> --
> С уважением
> Михаил Шогин.
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>



-- 
WBR, Yury Pats
skype: yuripats
cellular: +375 (29) 5870723

From chesnokov.ilya на gmail.com  Fri Oct 28 03:36:07 2011
From: chesnokov.ilya на gmail.com (Ilya Chesnokov)
Date: Fri, 28 Oct 2011 14:36:07 +0400
Subject: [Moscow.pm] =?utf-8?b?0J7RgtC60LvRjtGH0LXQvdC40LUgd2FybmluZ3Mg?=
	=?utf-8?q?=27uninitialized=27?=
Message-ID: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>

Всем привет.

Может быть глупый вопрос, но всё же интересно: какова мотивация того,
что в модулях типа common::sense и uni::perl отключены предупреждения
об "uninitialized value"?

С одной стороны это понятно, да и в документации common::sense явно
сказано:"undef is a well-defined feature of perl, and enabling
warnings for using it rarely catches any bugs, but considerably limits
you in what you can do" -- но реально хоть и редко, но баги всё же
отлавливаются. Причём такие баги, о которых в противном случае можно
было бы и не догадаться.

Другими словами: на что надеются программисты, когда отключают эти
предупреждения -- как ловят баги?

-- 
Best regards,
Ilya Chesnokov

From ivan на stack.net  Fri Oct 28 02:34:52 2011
From: ivan на stack.net (Ivan Panchenko)
Date: Fri, 28 Oct 2011 13:34:52 +0400
Subject: [Moscow.pm] =?utf-8?b?0YLRgtGC0YIgWyDQsNC8TW9zY293LnBtXQnQoNCw?=
 =?utf-8?b?0LfQvNGL0YjQu9C10L3QuNGPINC90LAg0YLQtdC80YMgT1JNINC4INCy0L4=?=
 =?utf-8?b?0L7QsdGJ0LXRhtC60YMg0YDQsNCx0L7QtdC70LzRgtGLINC8ICDQtSDQsC4=?=
 =?utf-8?q?=D0=BB=D0=B0_uuoklfifffffffyifufffffffffuuufffufcfhvfghcgfufiff?=
 =?utf-8?b?ZmZ1aGhwcG9vb3BsbWtmZtGBINCR0JQ=?=
Message-ID: <jjxetxmywty3ciy1gi0ahfpx.1319793579655@email.android.com>


Lolllb
Fpkppbubbp

Михаил Шогин <mshogin на gmail.com> написал(а):

>>
>> > Мда, долгая дискуссия.
>> >
>> > ORM - зло!
>> >
>> > Что такое SQL ( в простом определении ) - это то что мы хотим получить и
>> > ПУТЬ получения данных.
>> > При использовании ORM и конструкторов запросов, мы не черта не знаем
>> каким
>> > путем мы получаем данные, а это самое главное.
>> > Как оптимизировать запросы? Как закреплять планы выполнения?
>> > Ведь в каком то случае лучше использовать HASH JOIN, а в каком то NESTED
>> > LOOP.
>> >
>> > Даже банальная фильтрация данных может идти несколькими различными
>> путями:
>> >  - table full scan
>> >  - index range scan + table access by rowid
>> >  - index range scan
>> >  - index full scan
>> >
>> > Как всем этим управлять?
>>
>> Фишка здесь в том что такой микроскоп нужен на 1 из 100 запросов. Хватай
>> голый $dbh из DBIC и делай что хочеш. Ведь нигде не сказано что раз DBIC
>> так всегда DBIC. Надо все таки уметь сообразить когда пора положить молоток
>> и взять отвертку :)
>>
>
>Хех, нет, у нас не так. Запросы оптимизируются перед использованием в коде.
>+ выставляются хинты для быстрого выявления тормозных запросов.
>
>
>
>-- 
>С уважением
>Михаил Шогин.
>Tel: +7 915 0311328
>ICQ: 266776394
>
>-- 
>Moscow.pm mailing list
>moscow-pm на pm.org | http://moscow.pm.org

From i.petro.77.00 на gmail.com  Fri Oct 28 04:08:10 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 15:08:10 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <20111028101532.GK24610@rabbit.us>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
Message-ID: <20111028110809.GN20514@apache.rbscorp.ru>

> Твой аргумент какой то дикий - разница м/у DBIC и писать ручками SQL
> подобна той между Perl и писать ручками assembler. Тебе Perl часом не
> мешает?

неуместное сравнение.

говорить о DBIC vs писать SQL ручками вообще нельзя. ибо DBIC умеет
составлять только самые простые запросы.

а на реальных задачах получаются либо извращения (вроде специальные
VIEW'ы дабы DBIC в них смотрел и не пытался самостоятельничать), либо
те же запросы ручками

From denis.fedoseev на gmail.com  Fri Oct 28 04:09:10 2011
From: denis.fedoseev на gmail.com (Denis Fedoseev)
Date: Fri, 28 Oct 2011 15:09:10 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?79TLzMDexc7JxSB3YXJuaW5ncyAndW5pbml0aWFs?=
	=?koi8-r?b?aXplZCc=?=
In-Reply-To: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
Message-ID: <CALE3dTUiM6XuPGVFMuPVLVZb9hO2rZ4ff8JgMsBF4dT=BAyWCg@mail.gmail.com>

Ну есть мнение, что баги ловятся тестами, а для дебага варнинги включить не
проблема.

28.10.2011 14:36 пользователь "Ilya Chesnokov" <chesnokov.ilya на gmail.com>
написал:

Всем привет.

Может быть глупый вопрос, но всё же интересно: какова мотивация того,
что в модулях типа common::sense и uni::perl отключены предупреждения
об "uninitialized value"?

С одной стороны это понятно, да и в документации common::sense явно
сказано:"undef is a well-defined feature of perl, and enabling
warnings for using it rarely catches any bugs, but considerably limits
you in what you can do" -- но реально хоть и редко, но баги всё же
отлавливаются. Причём такие баги, о которых в противном случае можно
было бы и не догадаться.

Другими словами: на что надеются программисты, когда отключают эти
предупреждения -- как ловят баги?

--
Best regards,
Ilya Chesnokov
--
Moscow.pm mailing list
moscow-pm на pm.org | http://moscow.pm.org
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/8c5b295f/attachment.html>

From i.petro.77.00 на gmail.com  Fri Oct 28 04:10:31 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 15:10:31 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <CAFtO3fn3n0VeaTh8NtOyYpyiJQeeiVxO9OKBNbV=bhCcSXe7Kw@mail.gmail.com>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<CAFtO3fn3n0VeaTh8NtOyYpyiJQeeiVxO9OKBNbV=bhCcSXe7Kw@mail.gmail.com>
Message-ID: <20111028111031.GO20514@apache.rbscorp.ru>

> А что рельсы отменили?

у нас есть Mojo, но это не то. и в рельсах и в Mojo темплейты.

то есть ручное рисование html.
а раз местная аудитория утверждает что темплейты в SQL нафиг не нужны,
поскольку удалось все так круто автоматизировать, шо "оно само все
делает", я и предлагаю им пойти дальше. и отказаться от темплейтов в
html. зачем?

From andrei.protasovitski на gmail.com  Fri Oct 28 04:11:09 2011
From: andrei.protasovitski на gmail.com (Andrei)
Date: Fri, 28 Oct 2011 13:11:09 +0200
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <20111028110809.GN20514@apache.rbscorp.ru>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
Message-ID: <CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>

28 октября 2011 г. 13:08 пользователь Ivan Petrov
<i.petro.77.00 на gmail.com>написал:

> > Твой аргумент какой то дикий - разница м/у DBIC и писать ручками SQL
> > подобна той между Perl и писать ручками assembler. Тебе Perl часом не
> > мешает?
>
> неуместное сравнение.
>
> говорить о DBIC vs писать SQL ручками вообще нельзя. ибо DBIC умеет
> составлять только самые простые запросы.
>
> а на реальных задачах получаются либо извращения (вроде специальные
> VIEW'ы дабы DBIC в них смотрел и не пытался самостоятельничать), либо
> те же запросы ручками
>


DBIC автоматизиреут наиболее частые простые задачи.

-- 
Andrei Protasovitski
< andrei[dot]protasovitski[at]gmail[dot]com >
Diemen, Netherlands
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/a5555a45/attachment-0001.html>

From i.petro.77.00 на gmail.com  Fri Oct 28 04:12:09 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 15:12:09 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <20111028101000.GJ24610@rabbit.us>
References: <20111028064640.GB24610@rabbit.us>
	<20111028070352.GF20514@apache.rbscorp.ru>
	<20111028071248.GC24610@rabbit.us>
	<20111028072215.GH20514@apache.rbscorp.ru>
	<CALzA1My8HEzGXkOv5E_SJpvOpdDqu8dJCGyZTBrVBY3SuqDvyQ@mail.gmail.com>
	<20111028075715.GE24610@rabbit.us>
	<CALzA1Mz+zZccQ5qzM=_W+j8KWGa=REfLw6qbG5abaViv5H=0Kg@mail.gmail.com>
	<20111028081811.GF24610@rabbit.us>
	<20111028085625.GJ20514@apache.rbscorp.ru>
	<20111028101000.GJ24610@rabbit.us>
Message-ID: <20111028111208.GP20514@apache.rbscorp.ru>

>>>> Хех, нет, у нас не так. Запросы оптимизируются перед использованием в коде.
>>>> + выставляются хинты для быстрого выявления тормозных запросов.
>> 
>>> Хех, ну если для вашей конторы такой уровен premature optimisation привидно
>>> оптавдан (ибо никогда не может быть *реально* оправдан) - то с DBIC, да и
>>> вообще любым генератором вам не по пути :)
>> 
>> это потому что нормальный генератор запросов в современных условиях
>> (отстутсует AI) сделать невозможно.

> Прошло часов 15 с тех пор как я подключился - еще не одного примера где
> SQL генератор сделал что либо не так. 

я пример задачи давал. сразу на этой задаче ты предложил делать
множетсов запросов, успокаивая себя тем что множество будет не сильно
медленнее одного


From i.petro.77.00 на gmail.com  Fri Oct 28 04:12:41 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 15:12:41 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
	<CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
Message-ID: <20111028111240.GQ20514@apache.rbscorp.ru>


>>> не все БД поддерживают FOREIGN. соответственно ожидалось что при
>>> удалении объекта отношения другой объект либо "молча" обновится (что
>>> должно быть управляемо), либо будет помечен как измененный.

>> У нас есть кошка и корм для нее. Кошка от него зависит. Корм кончился -
>> изменилась ли кошка?

> именно!

> Хорошо, раз вы не знаете ответа, то я отвечу: кошка не изменилась.

ну если "сдохла с голоду" кошку не меняет. то да

From cub.uanic на gmail.com  Fri Oct 28 04:14:08 2011
From: cub.uanic на gmail.com (Oleg Kostyuk)
Date: Fri, 28 Oct 2011 14:14:08 +0300
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111028111208.GP20514@apache.rbscorp.ru>
References: <20111028064640.GB24610@rabbit.us>
	<20111028070352.GF20514@apache.rbscorp.ru>
	<20111028071248.GC24610@rabbit.us>
	<20111028072215.GH20514@apache.rbscorp.ru>
	<CALzA1My8HEzGXkOv5E_SJpvOpdDqu8dJCGyZTBrVBY3SuqDvyQ@mail.gmail.com>
	<20111028075715.GE24610@rabbit.us>
	<CALzA1Mz+zZccQ5qzM=_W+j8KWGa=REfLw6qbG5abaViv5H=0Kg@mail.gmail.com>
	<20111028081811.GF24610@rabbit.us>
	<20111028085625.GJ20514@apache.rbscorp.ru>
	<20111028101000.GJ24610@rabbit.us>
	<20111028111208.GP20514@apache.rbscorp.ru>
Message-ID: <CAAPa60i8ReijK62jQSKkupKenqvdbV6pP0Lz+vt2ZSja_jGZRw@mail.gmail.com>

Товарищ Петров, общественность уже неоднократно просила, и я
присоединюсь - покажите таки ваши исходники и полученные запросы, ну и
результат после ваших оптимизаций тоже. А то получается "я тут (на
блатной козе) приехал вам рассказать как всё плохо", и далее только
ваше мнение, не подкрепленное абсолютно ничем. Ну мы же врослые люди,
да? И любим хорошо обоснованную аргументацию. Или вам надо, чтоб вся
рассылка просила? Или какое-то другое особое обращение? Короче,
давайте, разоблачайтесь :)


28 октября 2011 г. 14:12 пользователь Ivan Petrov
<i.petro.77.00 на gmail.com> написал:
>>>>> Хех, нет, у нас не так. Запросы оптимизируются перед использованием в коде.
>>>>> + выставляются хинты для быстрого выявления тормозных запросов.
>>>
>>>> Хех, ну если для вашей конторы такой уровен premature optimisation привидно
>>>> оптавдан (ибо никогда не может быть *реально* оправдан) - то с DBIC, да и
>>>> вообще любым генератором вам не по пути :)
>>>
>>> это потому что нормальный генератор запросов в современных условиях
>>> (отстутсует AI) сделать невозможно.
>
>> Прошло часов 15 с тех пор как я подключился - еще не одного примера где
>> SQL генератор сделал что либо не так.
>
> я пример задачи давал. сразу на этой задаче ты предложил делать
> множетсов запросов, успокаивая себя тем что множество будет не сильно
> медленнее одного
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
Sincerely yours,
Oleg Kostyuk (CUB-UANIC)

From cub.uanic на gmail.com  Fri Oct 28 04:17:05 2011
From: cub.uanic на gmail.com (Oleg Kostyuk)
Date: Fri, 28 Oct 2011 14:17:05 +0300
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111028111240.GQ20514@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
	<CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
	<20111028111240.GQ20514@apache.rbscorp.ru>
Message-ID: <CAAPa60hHWoyN3dzxPpi_EQBL3=t4=Y3CqiUXp7=6F1bdKWChqA@mail.gmail.com>

28 октября 2011 г. 14:12 пользователь Ivan Petrov
<i.petro.77.00 на gmail.com> написал:
>
>>>> не все БД поддерживают FOREIGN. соответственно ожидалось что при
>>>> удалении объекта отношения другой объект либо "молча" обновится (что
>>>> должно быть управляемо), либо будет помечен как измененный.
>
>>> У нас есть кошка и корм для нее. Кошка от него зависит. Корм кончился -
>>> изменилась ли кошка?
>
>> именно!
>
>> Хорошо, раз вы не знаете ответа, то я отвечу: кошка не изменилась.
>
> ну если "сдохла с голоду" кошку не меняет. то да

Какая нежная у вас кошка.
Вы ей конечно новый пакет в кормом не купите, да?
И наличие двух пакетов сразу конечно же тоже кошку меняет?

> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
Sincerely yours,
Oleg Kostyuk (CUB-UANIC)

From andrei.protasovitski на gmail.com  Fri Oct 28 04:18:25 2011
From: andrei.protasovitski на gmail.com (Andrei)
Date: Fri, 28 Oct 2011 13:18:25 +0200
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111028111208.GP20514@apache.rbscorp.ru>
References: <20111028064640.GB24610@rabbit.us>
	<20111028070352.GF20514@apache.rbscorp.ru>
	<20111028071248.GC24610@rabbit.us>
	<20111028072215.GH20514@apache.rbscorp.ru>
	<CALzA1My8HEzGXkOv5E_SJpvOpdDqu8dJCGyZTBrVBY3SuqDvyQ@mail.gmail.com>
	<20111028075715.GE24610@rabbit.us>
	<CALzA1Mz+zZccQ5qzM=_W+j8KWGa=REfLw6qbG5abaViv5H=0Kg@mail.gmail.com>
	<20111028081811.GF24610@rabbit.us>
	<20111028085625.GJ20514@apache.rbscorp.ru>
	<20111028101000.GJ24610@rabbit.us>
	<20111028111208.GP20514@apache.rbscorp.ru>
Message-ID: <CANVWn7EK0Yh_o6JznSJnzRazpswBLz6paNjyWc9MkDSGOHq-Uw@mail.gmail.com>

28 октября 2011 г. 13:12 пользователь Ivan Petrov
<i.petro.77.00 на gmail.com>написал:

> >>>> Хех, нет, у нас не так. Запросы оптимизируются перед использованием в
> коде.
> >>>> + выставляются хинты для быстрого выявления тормозных запросов.
> >>
> >>> Хех, ну если для вашей конторы такой уровен premature optimisation
> привидно
> >>> оптавдан (ибо никогда не может быть *реально* оправдан) - то с DBIC, да
> и
> >>> вообще любым генератором вам не по пути :)
> >>
> >> это потому что нормальный генератор запросов в современных условиях
> >> (отстутсует AI) сделать невозможно.
>
> > Прошло часов 15 с тех пор как я подключился - еще не одного примера где
> > SQL генератор сделал что либо не так.
>
> я пример задачи давал. сразу на этой задаче ты предложил делать
> множетсов запросов, успокаивая себя тем что множество будет не сильно
> медленнее одного
>

Про несколько (а не множество) запросов говорил я, а не сын кролика. И
именно так работает ORM. А запрос, который тут приводился в качестве
примера, непонятно какую задачу решает. Задачи как таковой не было, было
нытьё по поводу того, что ORM не позволяет решить задачу определённым
способом.

-- 
Andrei Protasovitski
< andrei[dot]protasovitski[at]gmail[dot]com >
Diemen, Netherlands
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/53fca8ce/attachment-0001.html>

From rabbit+moscowpm на rabbit.us  Fri Oct 28 04:19:32 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 07:19:32 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111028111208.GP20514@apache.rbscorp.ru>
References: <20111028070352.GF20514@apache.rbscorp.ru>
	<20111028071248.GC24610@rabbit.us>
	<20111028072215.GH20514@apache.rbscorp.ru>
	<CALzA1My8HEzGXkOv5E_SJpvOpdDqu8dJCGyZTBrVBY3SuqDvyQ@mail.gmail.com>
	<20111028075715.GE24610@rabbit.us>
	<CALzA1Mz+zZccQ5qzM=_W+j8KWGa=REfLw6qbG5abaViv5H=0Kg@mail.gmail.com>
	<20111028081811.GF24610@rabbit.us>
	<20111028085625.GJ20514@apache.rbscorp.ru>
	<20111028101000.GJ24610@rabbit.us>
	<20111028111208.GP20514@apache.rbscorp.ru>
Message-ID: <20111028111931.GQ24610@rabbit.us>

On Fri, Oct 28, 2011 at 03:12:09PM +0400, Ivan Petrov wrote:
> >>>> Хех, нет, у нас не так. Запросы оптимизируются перед использованием в коде.
> >>>> + выставляются хинты для быстрого выявления тормозных запросов.
> >> 
> >>> Хех, ну если для вашей конторы такой уровен premature optimisation привидно
> >>> оптавдан (ибо никогда не может быть *реально* оправдан) - то с DBIC, да и
> >>> вообще любым генератором вам не по пути :)
> >> 
> >> это потому что нормальный генератор запросов в современных условиях
> >> (отстутсует AI) сделать невозможно.
> 
> > Прошло часов 15 с тех пор как я подключился - еще не одного примера где
> > SQL генератор сделал что либо не так. 
> 
> я пример задачи давал. сразу на этой задаче ты предложил делать
> множетсов запросов, успокаивая себя тем что множество будет не сильно
> медленнее одного
> 

Кто я?! Где? Линк прошу в студию. Если имееш ввиду
http://mail.pm.org/pipermail/moscow-pm/2011-October/010828.html
так то ведь не я :)

Вон он я:
http://mail.pm.org/pipermail/moscow-pm/2011-October/010827.html

From andrei.protasovitski на gmail.com  Fri Oct 28 04:19:59 2011
From: andrei.protasovitski на gmail.com (Andrei)
Date: Fri, 28 Oct 2011 13:19:59 +0200
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111028111240.GQ20514@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
	<CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
	<20111028111240.GQ20514@apache.rbscorp.ru>
Message-ID: <CANVWn7GbtdnAeyvB+gT812cb7T+t1NwEgJyZHG9Q7sW0zeK4Dg@mail.gmail.com>

28 октября 2011 г. 13:12 пользователь Ivan Petrov
<i.petro.77.00 на gmail.com>написал:

>
> >>> не все БД поддерживают FOREIGN. соответственно ожидалось что при
> >>> удалении объекта отношения другой объект либо "молча" обновится (что
> >>> должно быть управляемо), либо будет помечен как измененный.
>
> >> У нас есть кошка и корм для нее. Кошка от него зависит. Корм кончился -
> >> изменилась ли кошка?
>
> > именно!
>
> > Хорошо, раз вы не знаете ответа, то я отвечу: кошка не изменилась.
>
> ну если "сдохла с голоду" кошку не меняет. то да
>

Вы подменяете понятия класса и объекта. Корм, который закончился, это
объект. Чтобы кошка сдохла, нужно чтобы "закончился" корм как класс.

-- 
Andrei Protasovitski
< andrei[dot]protasovitski[at]gmail[dot]com >
Diemen, Netherlands
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/3bc5dddd/attachment.html>

From i.petro.77.00 на gmail.com  Fri Oct 28 04:21:24 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 15:21:24 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
	<CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
Message-ID: <20111028112123.GR20514@apache.rbscorp.ru>


> Вообще неплохо бы научиться понимать, что, с чем и как связано. В случае
> пользователь-задача нужно чётко осознавать, что пользователь суть свойство
> задачи, а не наоборот.

нет. одна задача назначается сразу нескольким пользователям.

соответственно не пользователь - свойство задачи, а пользователИ

это если говорить о первом примере

если говорить о втором примере, то замените task на user_card. хотя
бизнес изредка подкидывает и такие абстракции, как задача - свойство
пользователя.

мы говорили о проблеме отслеживания связей двух объектов

user->user_card->delete

поскольку user_card (или task во втором примере) выбирается по
указателю внутри user, то удаление user_card (или task во втором
примере) должно менять user

в БД это решается FOREIGN'ами. в DBIC это не решается

From rabbit+moscowpm на rabbit.us  Fri Oct 28 04:22:45 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 07:22:45 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <CANVWn7EK0Yh_o6JznSJnzRazpswBLz6paNjyWc9MkDSGOHq-Uw@mail.gmail.com>
References: <20111028071248.GC24610@rabbit.us>
	<20111028072215.GH20514@apache.rbscorp.ru>
	<CALzA1My8HEzGXkOv5E_SJpvOpdDqu8dJCGyZTBrVBY3SuqDvyQ@mail.gmail.com>
	<20111028075715.GE24610@rabbit.us>
	<CALzA1Mz+zZccQ5qzM=_W+j8KWGa=REfLw6qbG5abaViv5H=0Kg@mail.gmail.com>
	<20111028081811.GF24610@rabbit.us>
	<20111028085625.GJ20514@apache.rbscorp.ru>
	<20111028101000.GJ24610@rabbit.us>
	<20111028111208.GP20514@apache.rbscorp.ru>
	<CANVWn7EK0Yh_o6JznSJnzRazpswBLz6paNjyWc9MkDSGOHq-Uw@mail.gmail.com>
Message-ID: <20111028112244.GR24610@rabbit.us>

On Fri, Oct 28, 2011 at 01:18:25PM +0200, Andrei wrote:
> 28 октября 2011 г. 13:12 пользователь Ivan Petrov
> <i.petro.77.00 на gmail.com>написал:
> 
> > >>>> Хех, нет, у нас не так. Запросы оптимизируются перед использованием в
> > коде.
> > >>>> + выставляются хинты для быстрого выявления тормозных запросов.
> > >>
> > >>> Хех, ну если для вашей конторы такой уровен premature optimisation
> > привидно
> > >>> оптавдан (ибо никогда не может быть *реально* оправдан) - то с DBIC, да
> > и
> > >>> вообще любым генератором вам не по пути :)
> > >>
> > >> это потому что нормальный генератор запросов в современных условиях
> > >> (отстутсует AI) сделать невозможно.
> >
> > > Прошло часов 15 с тех пор как я подключился - еще не одного примера где
> > > SQL генератор сделал что либо не так.
> >
> > я пример задачи давал. сразу на этой задаче ты предложил делать
> > множетсов запросов, успокаивая себя тем что множество будет не сильно
> > медленнее одного
> >
> 
> Про несколько (а не множество) запросов говорил я, а не сын кролика. И
> именно так работает ORM.

Опять чуш :) Я лично два месяца положил чтоб все в одном запросе делалось,
не доделал совсем совсем до конца, но близко. Для большинства случаев работает,
но не имея изходника я не могу судить что там товарищ Петров намутил.

Чтоб совсем рай на земле - Надо есще месяц положить :)

From akzhan.abdulin на gmail.com  Fri Oct 28 04:22:46 2011
From: akzhan.abdulin на gmail.com (Akzhan Abdulin)
Date: Fri, 28 Oct 2011 15:22:46 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <20111028090209.GK20514@apache.rbscorp.ru>
References: <20111028090209.GK20514@apache.rbscorp.ru>
Message-ID: <CAGOcgF2WMe=8oJv5P+ZWwe3T4DZ238aWZZLh1+Y8o5xU-oMx-w@mail.gmail.com>

Намекну про наличие ASP.NET Web Forms. Там и вправду дизайн рисуется.

Равно как есть и Flash, Silverlight.

Но, что интересно, наличие Web Forms не помешало позднее успешному старту
ASP.NET MVC.

28 октября 2011 г. 13:02 пользователь Ivan Petrov
<i.petro.77.00 на gmail.com>написал:

> В продолжение к теме про ORM.
>
> Ребят, если у вас все так клево получается и запросы сами
> генерируются, качественно.
> то может вы напишите автогенератор сайтов?
>
> что нафиг все вебразработчики трахаются, темплейты какие-то.
> ну их нафиг!
>
> давайте сделайте автогенерацию, пусть они только опишут в виде
> хешей что им надо, передадут эти хеши вашей функции и вы им сайт с уже
> готовыми текстами, формами итп выдадите.
>
> это ж клондайк! и главное (по вашему) реализуемо!
>
> ;) <- смайлик тут
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/45736b88/attachment-0001.html>

From i.petro.77.00 на gmail.com  Fri Oct 28 04:23:09 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 15:23:09 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <CAAPa60hHWoyN3dzxPpi_EQBL3=t4=Y3CqiUXp7=6F1bdKWChqA@mail.gmail.com>
References: <20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
	<CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
	<20111028111240.GQ20514@apache.rbscorp.ru>
	<CAAPa60hHWoyN3dzxPpi_EQBL3=t4=Y3CqiUXp7=6F1bdKWChqA@mail.gmail.com>
Message-ID: <20111028112309.GS20514@apache.rbscorp.ru>

>>>>> не все БД поддерживают FOREIGN. соответственно ожидалось что при
>>>>> удалении объекта отношения другой объект либо "молча" обновится (что
>>>>> должно быть управляемо), либо будет помечен как измененный.
>> 
>>>> У нас есть кошка и корм для нее. Кошка от него зависит. Корм кончился -
>>>> изменилась ли кошка?
>> 
>>> именно!
>> 
>>> Хорошо, раз вы не знаете ответа, то я отвечу: кошка не изменилась.
>> 
>> ну если "сдохла с голоду" кошку не меняет. то да

> Какая нежная у вас кошка.
> Вы ей конечно новый пакет в кормом не купите, да?
> И наличие двух пакетов сразу конечно же тоже кошку меняет?

применительно к БД. Ваша кошка владеет призраком еды, даже когда она у
нее кончается.

From i.petro.77.00 на gmail.com  Fri Oct 28 04:24:41 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 15:24:41 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <20111028111931.GQ24610@rabbit.us>
References: <20111028071248.GC24610@rabbit.us>
	<20111028072215.GH20514@apache.rbscorp.ru>
	<CALzA1My8HEzGXkOv5E_SJpvOpdDqu8dJCGyZTBrVBY3SuqDvyQ@mail.gmail.com>
	<20111028075715.GE24610@rabbit.us>
	<CALzA1Mz+zZccQ5qzM=_W+j8KWGa=REfLw6qbG5abaViv5H=0Kg@mail.gmail.com>
	<20111028081811.GF24610@rabbit.us>
	<20111028085625.GJ20514@apache.rbscorp.ru>
	<20111028101000.GJ24610@rabbit.us>
	<20111028111208.GP20514@apache.rbscorp.ru>
	<20111028111931.GQ24610@rabbit.us>
Message-ID: <20111028112440.GT20514@apache.rbscorp.ru>

>>>>>> Хех, нет, у нас не так. Запросы оптимизируются перед использованием в коде.
>>>>>> + выставляются хинты для быстрого выявления тормозных запросов.
>>>> 
>>>>> Хех, ну если для вашей конторы такой уровен premature optimisation привидно
>>>>> оптавдан (ибо никогда не может быть *реально* оправдан) - то с DBIC, да и
>>>>> вообще любым генератором вам не по пути :)
>>>> 
>>>> это потому что нормальный генератор запросов в современных условиях
>>>> (отстутсует AI) сделать невозможно.
>> 
>>> Прошло часов 15 с тех пор как я подключился - еще не одного примера где
>>> SQL генератор сделал что либо не так.
>> 
>> я пример задачи давал. сразу на этой задаче ты предложил делать
>> множетсов запросов, успокаивая себя тем что множество будет не сильно
>> медленнее одного
>> 

> Кто я?! Где? Линк прошу в студию. Если имееш ввиду
> http://mail.pm.org/pipermail/moscow-pm/2011-October/010828.html
> так то ведь не я :)

прошу пардону перепутал


From i.petro.77.00 на gmail.com  Fri Oct 28 04:26:22 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 15:26:22 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <20111028112244.GR24610@rabbit.us>
References: <20111028072215.GH20514@apache.rbscorp.ru>
	<CALzA1My8HEzGXkOv5E_SJpvOpdDqu8dJCGyZTBrVBY3SuqDvyQ@mail.gmail.com>
	<20111028075715.GE24610@rabbit.us>
	<CALzA1Mz+zZccQ5qzM=_W+j8KWGa=REfLw6qbG5abaViv5H=0Kg@mail.gmail.com>
	<20111028081811.GF24610@rabbit.us>
	<20111028085625.GJ20514@apache.rbscorp.ru>
	<20111028101000.GJ24610@rabbit.us>
	<20111028111208.GP20514@apache.rbscorp.ru>
	<CANVWn7EK0Yh_o6JznSJnzRazpswBLz6paNjyWc9MkDSGOHq-Uw@mail.gmail.com>
	<20111028112244.GR24610@rabbit.us>
Message-ID: <20111028112622.GU20514@apache.rbscorp.ru>

> Опять чуш :) Я лично два месяца положил чтоб все в одном запросе делалось,

дык, речь же вроде идет о том что ентот енструмент помогает делать
работу быстро.

а ты месяцами над одним запросом пухнешь.

взял бы его просто и написал, зачем DBIC?

From rabbit+moscowpm на rabbit.us  Fri Oct 28 04:26:49 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 07:26:49 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111028112123.GR20514@apache.rbscorp.ru>
References: <20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
	<CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
	<20111028112123.GR20514@apache.rbscorp.ru>
Message-ID: <20111028112649.GS24610@rabbit.us>

On Fri, Oct 28, 2011 at 03:21:24PM +0400, Ivan Petrov wrote:
> 
> > Вообще неплохо бы научиться понимать, что, с чем и как связано. В случае
> > пользователь-задача нужно чётко осознавать, что пользователь суть свойство
> > задачи, а не наоборот.
> 
> нет. одна задача назначается сразу нескольким пользователям.
> 
> соответственно не пользователь - свойство задачи, а пользователИ
> 
> это если говорить о первом примере
> 
> если говорить о втором примере, то замените task на user_card. хотя
> бизнес изредка подкидывает и такие абстракции, как задача - свойство
> пользователя.
> 
> мы говорили о проблеме отслеживания связей двух объектов
> 
> user->user_card->delete
> 
> поскольку user_card (или task во втором примере) выбирается по
> указателю внутри user, то удаление user_card (или task во втором
> примере) должно менять user
> 
> в БД это решается FOREIGN'ами. в DBIC это не решается

Почему такой яростный упор на то что в DBIC что то не решается. Отслеживать
состояние (state) смежных объетков не реализована в DBIC ибо не является
задачей для ORM. Такая задача должна решатся на уровне более высоком,
например тот же Reaction.


From rabbit+moscowpm на rabbit.us  Fri Oct 28 04:28:38 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 07:28:38 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111028112622.GU20514@apache.rbscorp.ru>
References: <CALzA1My8HEzGXkOv5E_SJpvOpdDqu8dJCGyZTBrVBY3SuqDvyQ@mail.gmail.com>
	<20111028075715.GE24610@rabbit.us>
	<CALzA1Mz+zZccQ5qzM=_W+j8KWGa=REfLw6qbG5abaViv5H=0Kg@mail.gmail.com>
	<20111028081811.GF24610@rabbit.us>
	<20111028085625.GJ20514@apache.rbscorp.ru>
	<20111028101000.GJ24610@rabbit.us>
	<20111028111208.GP20514@apache.rbscorp.ru>
	<CANVWn7EK0Yh_o6JznSJnzRazpswBLz6paNjyWc9MkDSGOHq-Uw@mail.gmail.com>
	<20111028112244.GR24610@rabbit.us>
	<20111028112622.GU20514@apache.rbscorp.ru>
Message-ID: <20111028112838.GT24610@rabbit.us>

On Fri, Oct 28, 2011 at 03:26:22PM +0400, Ivan Petrov wrote:
> > Опять чуш :) Я лично два месяца положил чтоб все в одном запросе делалось,
> 
> дык, речь же вроде идет о том что ентот енструмент помогает делать
> работу быстро.
> 
> а ты месяцами над одним запросом пухнешь.
> 
> взял бы его просто и написал, зачем DBIC?

Я имел ввиду...
https://www.ohloh.net/p/dbix-class/contributors/45829448826658

Другими словами - именно чтоб никто не пухнул :)

From andrei.protasovitski на gmail.com  Fri Oct 28 04:29:18 2011
From: andrei.protasovitski на gmail.com (Andrei)
Date: Fri, 28 Oct 2011 13:29:18 +0200
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111028112123.GR20514@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
	<CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
	<20111028112123.GR20514@apache.rbscorp.ru>
Message-ID: <CANVWn7FQhN9efL1REmtvDbtD3D-Do7kZEjCSgXOApPB-Pkz+fA@mail.gmail.com>

28 октября 2011 г. 13:21 пользователь Ivan Petrov
<i.petro.77.00 на gmail.com>написал:

>
> > Вообще неплохо бы научиться понимать, что, с чем и как связано. В случае
> > пользователь-задача нужно чётко осознавать, что пользователь суть
> свойство
> > задачи, а не наоборот.
>
> нет. одна задача назначается сразу нескольким пользователям.
>
> соответственно не пользователь - свойство задачи, а пользователИ
>
> это если говорить о первом примере
>
> если говорить о втором примере, то замените task на user_card. хотя
> бизнес изредка подкидывает и такие абстракции, как задача - свойство
> пользователя.
>
> мы говорили о проблеме отслеживания связей двух объектов
>
> user->user_card->delete
>
> поскольку user_card (или task во втором примере) выбирается по
> указателю внутри user, то удаление user_card (или task во втором
> примере) должно менять user
>
> в БД это решается FOREIGN'ами. в DBIC это не решается
>

В БД это решается промежуточной таблицей, для которой в ORM делается
отдельный враппер. А умный программист ещё и перезназвачает акссессор для
is_changed, чтобы тот смотрел в промежуточную таблицу.

Кстати, FK прекрасно работают в ORM, даже если они не определены в описании
таблиц.

-- 
Andrei Protasovitski
< andrei[dot]protasovitski[at]gmail[dot]com >
Diemen, Netherlands
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/c4488868/attachment-0001.html>

From i.petro.77.00 на gmail.com  Fri Oct 28 04:30:08 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 15:30:08 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <20111028112649.GS24610@rabbit.us>
References: <20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
	<CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
	<20111028112123.GR20514@apache.rbscorp.ru>
	<20111028112649.GS24610@rabbit.us>
Message-ID: <20111028113008.GV20514@apache.rbscorp.ru>

> Почему такой яростный упор на то что в DBIC что то не решается. Отслеживать
> состояние (state) смежных объетков не реализована в DBIC ибо

отслеживать смежные объекты - не реализовано
конструировать запросы - плохо реализовано - ибо хорошо нереализуемо

и вот смысла в этом проекте получается нет. все что он делает -
изолирует не знающих SQL людей от SQL.

From andrey на kostenko.name  Fri Oct 28 04:33:24 2011
From: andrey на kostenko.name (=?UTF-8?B?0JDQvdC00YDQtdC5INCa0L7RgdGC0LXQvdC60L4=?=)
Date: Fri, 28 Oct 2011 15:33:24 +0400
Subject: [Moscow.pm] =?utf-8?b?0YLRgtGC0YIgWyDQsNC8TW9zY293LnBtXSDQoNCw?=
	=?utf-8?b?0LfQvNGL0YjQu9C10L3QuNGPINC90LAg0YLQtdC80YMgT1JNINC4INCy?=
	=?utf-8?b?0L7QvtCx0YnQtdGG0LrRgyDRgNCw0LHQvtC10LvQvNGC0Ysg0Lwg0LUg?=
	=?utf-8?q?=D0=B0=2E=D0=BB=D0=B0_uuoklfifffffffyifufffffffffuuufffu?=
	=?utf-8?q?fcfhvfghcgfufiffffuhhppoooplmkff=D1=81_=D0=91=D0=94?=
In-Reply-To: <jjxetxmywty3ciy1gi0ahfpx.1319793579655@email.android.com>
References: <jjxetxmywty3ciy1gi0ahfpx.1319793579655@email.android.com>
Message-ID: <CAME9Y=59g_NZnrPatjDHcv6=sRYS4D54K8h-_OZ1cMmCXFJ73g@mail.gmail.com>

Вот именно!

2011/10/28 Ivan Panchenko <ivan на stack.net>

>
> Lolllb
> Fpkppbubbp
>
> Михаил Шогин <mshogin на gmail.com> написал(а):
>
> >>
> >> > Мда, долгая дискуссия.
> >> >
> >> > ORM - зло!
> >> >
> >> > Что такое SQL ( в простом определении ) - это то что мы хотим получить
> и
> >> > ПУТЬ получения данных.
> >> > При использовании ORM и конструкторов запросов, мы не черта не знаем
> >> каким
> >> > путем мы получаем данные, а это самое главное.
> >> > Как оптимизировать запросы? Как закреплять планы выполнения?
> >> > Ведь в каком то случае лучше использовать HASH JOIN, а в каком то
> NESTED
> >> > LOOP.
> >> >
> >> > Даже банальная фильтрация данных может идти несколькими различными
> >> путями:
> >> >  - table full scan
> >> >  - index range scan + table access by rowid
> >> >  - index range scan
> >> >  - index full scan
> >> >
> >> > Как всем этим управлять?
> >>
> >> Фишка здесь в том что такой микроскоп нужен на 1 из 100 запросов. Хватай
> >> голый $dbh из DBIC и делай что хочеш. Ведь нигде не сказано что раз DBIC
> >> так всегда DBIC. Надо все таки уметь сообразить когда пора положить
> молоток
> >> и взять отвертку :)
> >>
> >
> >Хех, нет, у нас не так. Запросы оптимизируются перед использованием в
> коде.
> >+ выставляются хинты для быстрого выявления тормозных запросов.
> >
> >
> >
> >--
> >С уважением
> >Михаил Шогин.
> >Tel: +7 915 0311328
> >ICQ: 266776394
> >
> >--
> >Moscow.pm mailing list
> >moscow-pm на pm.org | http://moscow.pm.org
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/40f1d89a/attachment.html>

From chesnokov.ilya на gmail.com  Fri Oct 28 04:36:34 2011
From: chesnokov.ilya на gmail.com (Ilya Chesnokov)
Date: Fri, 28 Oct 2011 15:36:34 +0400
Subject: [Moscow.pm] =?utf-8?b?0J7RgtC60LvRjtGH0LXQvdC40LUgd2FybmluZ3Mg?=
	=?utf-8?q?=27uninitialized=27?=
In-Reply-To: <CALE3dTUiM6XuPGVFMuPVLVZb9hO2rZ4ff8JgMsBF4dT=BAyWCg@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<CALE3dTUiM6XuPGVFMuPVLVZb9hO2rZ4ff8JgMsBF4dT=BAyWCg@mail.gmail.com>
Message-ID: <CANh0x-xLAFRa-LoPsL1-Vd7hVvi-mU05B64uqkKBmyuyDzSHQA@mail.gmail.com>

28 октября 2011 г. 15:09 пользователь Denis Fedoseev
<denis.fedoseev на gmail.com> написал:
> Ну есть мнение, что баги ловятся тестами, а для дебага варнинги включить не
> проблема.

Вопрос только, насколько это мнение совпадает с реальностью.
Другими словами -- если нет тестов или их недостаточно (а сколько это
-- достаточно?), то варнинги лучше не отключать?

На самом деле вопрос в том, что я на работе хочу отключить эти самые
warnings 'uninitialized', но в реале получается, что они действительно
бывают полезны для отлова некоторых косяков.

Собственно поэтому и хочу спросить мнения у тех, кто это уже сделал и
на основании их опыта вывести некую "формулу" -- набор достаточных
условий для отключения этих варнингов.

-- 
Best regards,
Ilya Chesnokov

From jt на aaanet.ru  Fri Oct 28 04:35:59 2011
From: jt на aaanet.ru (=?utf-8?B?0JXQstCz0LXQvdC40Lkg0KLQvtGA0L7Qv9C+0LI=?=)
Date: Fri, 28 Oct 2011 15:35:59 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
Message-ID: <5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>

On Oct 28, 2011, at 3:11 PM, Andrei wrote:

> 28 октября 2011 г. 13:08 пользователь Ivan Petrov <i.petro.77.00 на gmail.com> написал:
> > Твой аргумент какой то дикий - разница м/у DBIC и писать ручками SQL
> > подобна той между Perl и писать ручками assembler. Тебе Perl часом не
> > мешает?
> 
> неуместное сравнение.
> 
> говорить о DBIC vs писать SQL ручками вообще нельзя. ибо DBIC умеет
> составлять только самые простые запросы.
> 
> а на реальных задачах получаются либо извращения (вроде специальные
> VIEW'ы дабы DBIC в них смотрел и не пытался самостоятельничать), либо
> те же запросы ручками
> 
> 
> DBIC автоматизиреут наиболее частые простые задачи.

Наиболее частые простые задачи автоматизируются примитивнейшими sql-генераторами и не стоят того, чтоб иметь пиздец какой оверхед ( http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/03/benchmarking-dbixclass-vs-plain-dbi-on-hailo.html ). Если бенчмарки по ссылке устарели - покажите новые.

Евгений
jt на aaanet.ru

> 
> -- 
> Andrei Protasovitski
> < andrei[dot]protasovitski[at]gmail[dot]com >
> Diemen, Netherlands
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/a8740b7c/attachment-0001.html>

From cub.uanic на gmail.com  Fri Oct 28 04:38:12 2011
From: cub.uanic на gmail.com (Oleg Kostyuk)
Date: Fri, 28 Oct 2011 14:38:12 +0300
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111028113008.GV20514@apache.rbscorp.ru>
References: <20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
	<CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
	<20111028112123.GR20514@apache.rbscorp.ru>
	<20111028112649.GS24610@rabbit.us>
	<20111028113008.GV20514@apache.rbscorp.ru>
Message-ID: <CAAPa60g6tZnvfr11e-GEt5jV=YbP+zsjWXJH+R1zTVedJN4hTA@mail.gmail.com>

28 октября 2011 г. 14:30 пользователь Ivan Petrov
<i.petro.77.00 на gmail.com> написал:
>> Почему такой яростный упор на то что в DBIC что то не решается. Отслеживать
>> состояние (state) смежных объетков не реализована в DBIC ибо
>
> отслеживать смежные объекты - не реализовано
> конструировать запросы - плохо реализовано - ибо хорошо нереализуемо
А аргументы-то где?...
Покажите нам это "плохо"!


> и вот смысла в этом проекте получается нет. все что он делает -
> изолирует не знающих SQL людей от SQL.
Всего лишь ваше личное мнение, не подкреплённое абсолютно ничем, в том
числе ни вашим кодом, ни тестами, ничем. Вы конечно же вселенский
разум и немеряный авторитет, и все должны поверить вам на слово?..


> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
Sincerely yours,
Oleg Kostyuk (CUB-UANIC)

From akzhan.abdulin на gmail.com  Fri Oct 28 04:39:45 2011
From: akzhan.abdulin на gmail.com (Akzhan Abdulin)
Date: Fri, 28 Oct 2011 15:39:45 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111028113008.GV20514@apache.rbscorp.ru>
References: <20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
	<CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
	<20111028112123.GR20514@apache.rbscorp.ru>
	<20111028112649.GS24610@rabbit.us>
	<20111028113008.GV20514@apache.rbscorp.ru>
Message-ID: <CAGOcgF0EO0p-3r9_V3tXt=JY_jGcwUO=wfPCxKUABQ0GV9ubTg@mail.gmail.com>

Иван, типичные ORM не предназначены для впихивания невпихуемого :)
Для большинства задач мне того же DBIx::Class или ActiveRecord хватает за
уши.

28 октября 2011 г. 15:30 пользователь Ivan Petrov
<i.petro.77.00 на gmail.com>написал:

> > Почему такой яростный упор на то что в DBIC что то не решается.
> Отслеживать
> > состояние (state) смежных объетков не реализована в DBIC ибо
>
> отслеживать смежные объекты - не реализовано
> конструировать запросы - плохо реализовано - ибо хорошо нереализуемо
>
> и вот смысла в этом проекте получается нет. все что он делает -
> изолирует не знающих SQL людей от SQL.
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/d08faf9a/attachment.html>

From rabbit+moscowpm на rabbit.us  Fri Oct 28 04:40:10 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 07:40:10 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111028113008.GV20514@apache.rbscorp.ru>
References: <20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
	<CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
	<20111028112123.GR20514@apache.rbscorp.ru>
	<20111028112649.GS24610@rabbit.us>
	<20111028113008.GV20514@apache.rbscorp.ru>
Message-ID: <20111028114010.GV24610@rabbit.us>

BBOn Fri, Oct 28, 2011 at 03:30:08PM +0400, Ivan Petrov wrote:
> > Почему такой яростный упор на то что в DBIC что то не решается. Отслеживать
> > состояние (state) смежных объетков не реализована в DBIC ибо
> 
> отслеживать смежные объекты - не реализовано

Ибо неуместно. Давай согласимся что здесь ты ожидаеш от DBIC чего то чего
в нем в принципе быть не должно, даже теоретически

> конструировать запросы - плохо реализовано - ибо хорошо нереализуемо

Вот заладил... Давай посчитаем сколько раз тебя просили показать что
собственно плохо:

http://mail.pm.org/pipermail/moscow-pm/2011-October/010808.html
http://mail.pm.org/pipermail/moscow-pm/2011-October/010810.html
http://mail.pm.org/pipermail/moscow-pm/2011-October/010818.html
http://mail.pm.org/pipermail/moscow-pm/2011-October/010824.html
http://mail.pm.org/pipermail/moscow-pm/2011-October/010827.html
http://mail.pm.org/pipermail/moscow-pm/2011-October/010849.html
http://mail.pm.org/pipermail/moscow-pm/2011-October/010860.html
http://mail.pm.org/pipermail/moscow-pm/2011-October/010873.html

Я извиняюсь перед рассылкой что такой тарарам подняли. Явно толку
не будет никакго. Я не буду больше отвечать на первый вопрос пока
не появится код (если другие вопросы - буду рад ответить :)

Еще раз - извиняюсь за шум, и за товарища Петрова тоже

From rabbit+moscowpm на rabbit.us  Fri Oct 28 04:42:50 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 07:42:50 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
Message-ID: <20111028114250.GW24610@rabbit.us>

On Fri, Oct 28, 2011 at 03:35:59PM +0400, Евгений Торопов wrote:
> On Oct 28, 2011, at 3:11 PM, Andrei wrote:
> 
> > 28 октября 2011 г. 13:08 пользователь Ivan Petrov <i.petro.77.00 на gmail.com> написал:
> > > Твой аргумент какой то дикий - разница м/у DBIC и писать ручками SQL
> > > подобна той между Perl и писать ручками assembler. Тебе Perl часом не
> > > мешает?
> > 
> > неуместное сравнение.
> > 
> > говорить о DBIC vs писать SQL ручками вообще нельзя. ибо DBIC умеет
> > составлять только самые простые запросы.
> > 
> > а на реальных задачах получаются либо извращения (вроде специальные
> > VIEW'ы дабы DBIC в них смотрел и не пытался самостоятельничать), либо
> > те же запросы ручками
> > 
> > 
> > DBIC автоматизиреут наиболее частые простые задачи.
> 
> Наиболее частые простые задачи автоматизируются примитивнейшими sql-генераторами и не стоят того, чтоб иметь пиздец какой оверхед ( http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/03/benchmarking-dbixclass-vs-plain-dbi-on-hailo.html ). Если бенчмарки по ссылке устарели - покажите новые.
> 

Здесь пока еще немного хромаем, но работа скоро опять пойдет полным паром.
Ставлю себе заметку оповестить рассылку когда закончится rewrite.


From zzz на zzz.org.ua  Fri Oct 28 04:43:14 2011
From: zzz на zzz.org.ua (Alexandr Gomoliako)
Date: Fri, 28 Oct 2011 14:43:14 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?79TLzMDexc7JxSB3YXJuaW5ncyAndW5pbml0aWFs?=
	=?koi8-r?b?aXplZCc=?=
Message-ID: <CAKb9G9hbKzHerOMtnRhC=EBvWcL+1TjcgeWZTZToy9rNxmPfWQ@mail.gmail.com>

On 10/28/11, Ilya Chesnokov <chesnokov.ilya на gmail.com> wrote:
> Всем привет.
>
> Может быть глупый вопрос, но всё же интересно: какова мотивация того,
> что в модулях типа common::sense и uni::perl отключены предупреждения
> об "uninitialized value"?

Более простой и читабельный код.

> С одной стороны это понятно, да и в документации common::sense явно
> сказано:"undef is a well-defined feature of perl, and enabling
> warnings for using it rarely catches any bugs, but considerably limits
> you in what you can do" -- но реально хоть и редко, но баги всё же
> отлавливаются. Причём такие баги, о которых в противном случае можно
> было бы и не догадаться.
>
> Другими словами: на что надеются программисты, когда отключают эти
> предупреждения -- как ловят баги?

Если натолкнетесь на баг, где есть хоть какая-то польза от uninitialized,
пишите. Я такой встречал только один раз и это был:
    sub m { .. }
    m "foo";

From zzz на zzz.org.ua  Fri Oct 28 04:43:52 2011
From: zzz на zzz.org.ua (Alexandr Gomoliako)
Date: Fri, 28 Oct 2011 14:43:52 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
	=?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
Message-ID: <CAKb9G9gFJhBrddvXm9hBwYcX2FPoEoyZLTLTj6haPwKEEB+42g@mail.gmail.com>

On 10/28/11, Peter Vereshagin <peter на vereshagin.org> wrote:
>> Разработка -- супер быстро, берете встроенный перл в nginx, JSON::XS
>> смотрите в $r->uri и генерите запросы к DBI, легко. К тому же ответы через

> это может быть рекомендовано?

> Есть мнение что пока встроенный perl в nginx блокируется, например, ждёт
> ответа из DBI, nginx хуже или вообще не отвечает остальным клиентам
> и т. о. perl встроенный в nginx для такого в общем случае не предназначен.

Вообще не отвечает, остальные ждут. Но можно запустить больше
воркеров и все станет хорошо. Т.е. вполне предназначен.
Да и nginx блокируется много где: на чтении файлов, директорий,
уменьшении картинок, генерации xslt, так что блокирование вообще
не проблема.

From rabbit+moscowpm на rabbit.us  Fri Oct 28 04:46:35 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 07:46:35 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
Message-ID: <20111028114635.GX24610@rabbit.us>

On Fri, Oct 28, 2011 at 03:35:59PM +0400, Евгений Торопов wrote:
> On Oct 28, 2011, at 3:11 PM, Andrei wrote:
> 
> > 28 октября 2011 г. 13:08 пользователь Ivan Petrov <i.petro.77.00 на gmail.com> написал:
> > > Твой аргумент какой то дикий - разница м/у DBIC и писать ручками SQL
> > > подобна той между Perl и писать ручками assembler. Тебе Perl часом не
> > > мешает?
> > 
> > неуместное сравнение.
> > 
> > говорить о DBIC vs писать SQL ручками вообще нельзя. ибо DBIC умеет
> > составлять только самые простые запросы.
> > 
> > а на реальных задачах получаются либо извращения (вроде специальные
> > VIEW'ы дабы DBIC в них смотрел и не пытался самостоятельничать), либо
> > те же запросы ручками
> > 
> > 
> > DBIC автоматизиреут наиболее частые простые задачи.
> 
> Наиболее частые простые задачи автоматизируются примитивнейшими sql-генераторами и не стоят того, чтоб иметь пиздец какой оверхед ( http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/03/benchmarking-dbixclass-vs-plain-dbi-on-hailo.html ). Если бенчмарки по ссылке устарели - покажите новые.
> 

Кстати оверхед изходит из "collapse" данных. Если пользоватся DBIC изключительно
как SQL генератором, и доставать данные из DBI напрямую ($rs->cursor->next/all)
то тогда оверхед практически нулевой. Конечно если верить что генерировать SQL
невозможно без AI не было бы смысла мне об етом тебе писать :)


From cub.uanic на gmail.com  Fri Oct 28 04:46:49 2011
From: cub.uanic на gmail.com (Oleg Kostyuk)
Date: Fri, 28 Oct 2011 14:46:49 +0300
Subject: [Moscow.pm] =?utf-8?b?0J7RgtC60LvRjtGH0LXQvdC40LUgd2FybmluZ3Mg?=
	=?utf-8?q?=27uninitialized=27?=
In-Reply-To: <CANh0x-xLAFRa-LoPsL1-Vd7hVvi-mU05B64uqkKBmyuyDzSHQA@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<CALE3dTUiM6XuPGVFMuPVLVZb9hO2rZ4ff8JgMsBF4dT=BAyWCg@mail.gmail.com>
	<CANh0x-xLAFRa-LoPsL1-Vd7hVvi-mU05B64uqkKBmyuyDzSHQA@mail.gmail.com>
Message-ID: <CAAPa60hJ4vvObcpoZiYpuvfxXCg3R-Nz6Ma=vhSDw80pBaRrTQ@mail.gmail.com>

У меня формула следующая:

1) common::sense и uni::perl не использую, потому как "а напуркуа"?
без них что-то не работает?
или это единственно верный путь?

2) no warnings - только в новом локальном блоке, и токлько на то, о
чем я сам знаю, что варнинг точно будет.
например, требуется разыменовать символическую ссылку.

Все остальные вагнинги воспринимаю как ошибки и правлю.


28 октября 2011 г. 14:36 пользователь Ilya Chesnokov
<chesnokov.ilya на gmail.com> написал:
> 28 октября 2011 г. 15:09 пользователь Denis Fedoseev
> <denis.fedoseev на gmail.com> написал:
>> Ну есть мнение, что баги ловятся тестами, а для дебага варнинги включить не
>> проблема.
>
> Вопрос только, насколько это мнение совпадает с реальностью.
> Другими словами -- если нет тестов или их недостаточно (а сколько это
> -- достаточно?), то варнинги лучше не отключать?
>
> На самом деле вопрос в том, что я на работе хочу отключить эти самые
> warnings 'uninitialized', но в реале получается, что они действительно
> бывают полезны для отлова некоторых косяков.
>
> Собственно поэтому и хочу спросить мнения у тех, кто это уже сделал и
> на основании их опыта вывести некую "формулу" -- набор достаточных
> условий для отключения этих варнингов.
>
> --
> Best regards,
> Ilya Chesnokov
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
Sincerely yours,
Oleg Kostyuk (CUB-UANIC)

From rabbit+moscowpm на rabbit.us  Fri Oct 28 04:49:17 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 07:49:17 -0400
Subject: [Moscow.pm] =?utf-8?b?0J7RgtC60LvRjtGH0LXQvdC40LUgd2FybmluZ3Mg?=
	=?utf-8?q?=27uninitialized=27?=
In-Reply-To: <CANh0x-xLAFRa-LoPsL1-Vd7hVvi-mU05B64uqkKBmyuyDzSHQA@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<CALE3dTUiM6XuPGVFMuPVLVZb9hO2rZ4ff8JgMsBF4dT=BAyWCg@mail.gmail.com>
	<CANh0x-xLAFRa-LoPsL1-Vd7hVvi-mU05B64uqkKBmyuyDzSHQA@mail.gmail.com>
Message-ID: <20111028114917.GY24610@rabbit.us>

On Fri, Oct 28, 2011 at 03:36:34PM +0400, Ilya Chesnokov wrote:
> На самом деле вопрос в том, что я на работе хочу отключить эти самые
> warnings 'uninitialized', но в реале получается, что они действительно
> бывают полезны для отлова некоторых косяков.

А можно поинтерисоватся зачем? Оверхед у strict/warnings практически
отсуствует (все реализованно в Sv флагах, которые переключаются *вне
зависимости* от того будет perl шипеть или нет).

From andrei.protasovitski на gmail.com  Fri Oct 28 04:51:00 2011
From: andrei.protasovitski на gmail.com (Andrei)
Date: Fri, 28 Oct 2011 13:51:00 +0200
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
Message-ID: <CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>

28 октября 2011 г. 13:35 пользователь Евгений Торопов <jt на aaanet.ru>написал:

> On Oct 28, 2011, at 3:11 PM, Andrei wrote:
>
> 28 октября 2011 г. 13:08 пользователь Ivan Petrov <i.petro.77.00 на gmail.com
> > написал:
>
>> > Твой аргумент какой то дикий - разница м/у DBIC и писать ручками SQL
>> > подобна той между Perl и писать ручками assembler. Тебе Perl часом не
>> > мешает?
>>
>> неуместное сравнение.
>>
>> говорить о DBIC vs писать SQL ручками вообще нельзя. ибо DBIC умеет
>> составлять только самые простые запросы.
>>
>> а на реальных задачах получаются либо извращения (вроде специальные
>> VIEW'ы дабы DBIC в них смотрел и не пытался самостоятельничать), либо
>> те же запросы ручками
>>
>
>
> DBIC автоматизиреут наиболее частые простые задачи.
>
>
> Наиболее частые простые задачи автоматизируются примитивнейшими
> sql-генераторами и не стоят того, чтоб иметь пиздец какой оверхед (
> http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/03/benchmarking-dbixclass-vs-plain-dbi-on-hailo.html ).
> Если бенчмарки по ссылке устарели - покажите новые.
>
>
Вы бы Айвара до конца читали. А там написано:

Even if it turns out that I'm doing everything right and there's no way to
make DBIx::Class faster than this for Hailo I'd still like to look into
using it. By converting to it I got rid of a lot of manual DBI tedium
required to support multiple backends.

А самый последний абзац вообще говорит:

Aside from this speed issue my first impressions of DBIx::Class have been
very positive. I'll probably use it for any future Perl code that accesses a
database. Provided the application isn't an oddball like Hailo which isn't
purely IO bound like most database-based programs.

-- 
Andrei Protasovitski
< andrei[dot]protasovitski[at]gmail[dot]com >
Diemen, Netherlands
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/e126aa9f/attachment.html>

From rabbit+moscowpm на rabbit.us  Fri Oct 28 04:59:49 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 07:59:49 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
Message-ID: <20111028115949.GZ24610@rabbit.us>

On Fri, Oct 28, 2011 at 01:51:00PM +0200, Andrei wrote:
> 28 октября 2011 г. 13:35 пользователь Евгений Торопов <jt на aaanet.ru>написал:
> 
> > On Oct 28, 2011, at 3:11 PM, Andrei wrote:
> >
> > 28 октября 2011 г. 13:08 пользователь Ivan Petrov <i.petro.77.00 на gmail.com
> > > написал:
> >
> >> > Твой аргумент какой то дикий - разница м/у DBIC и писать ручками SQL
> >> > подобна той между Perl и писать ручками assembler. Тебе Perl часом не
> >> > мешает?
> >>
> >> неуместное сравнение.
> >>
> >> говорить о DBIC vs писать SQL ручками вообще нельзя. ибо DBIC умеет
> >> составлять только самые простые запросы.
> >>
> >> а на реальных задачах получаются либо извращения (вроде специальные
> >> VIEW'ы дабы DBIC в них смотрел и не пытался самостоятельничать), либо
> >> те же запросы ручками
> >>
> >
> >
> > DBIC автоматизиреут наиболее частые простые задачи.
> >
> >
> > Наиболее частые простые задачи автоматизируются примитивнейшими
> > sql-генераторами и не стоят того, чтоб иметь пиздец какой оверхед (
> > http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/03/benchmarking-dbixclass-vs-plain-dbi-on-hailo.html ).
> > Если бенчмарки по ссылке устарели - покажите новые.
> >
> >
> Вы бы Айвара до конца читали. А там написано:
> 

А зачем мне его читать, когда я с ним лично говорил пока он замеры проводил :)
Я ктому ответил что "Да, у DBIC узких мест полно, о них знаем, над ними
работаем и если надо прямо чтоб сегодня быстро - надо так (->cursor)"


From jt на aaanet.ru  Fri Oct 28 04:59:40 2011
From: jt на aaanet.ru (=?utf-8?B?0JXQstCz0LXQvdC40Lkg0KLQvtGA0L7Qv9C+0LI=?=)
Date: Fri, 28 Oct 2011 15:59:40 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
Message-ID: <DA5EB15E-49FF-40B8-ADCF-DB0D1CCEF1D8@aaanet.ru>



On Oct 28, 2011, at 3:51 PM, Andrei wrote:

> 28 октября 2011 г. 13:35 пользователь Евгений Торопов <jt на aaanet.ru> написал:
> On Oct 28, 2011, at 3:11 PM, Andrei wrote:
> 
>> 28 октября 2011 г. 13:08 пользователь Ivan Petrov <i.petro.77.00 на gmail.com> написал:
>> > Твой аргумент какой то дикий - разница м/у DBIC и писать ручками SQL
>> > подобна той между Perl и писать ручками assembler. Тебе Perl часом не
>> > мешает?
>> 
>> неуместное сравнение.
>> 
>> говорить о DBIC vs писать SQL ручками вообще нельзя. ибо DBIC умеет
>> составлять только самые простые запросы.
>> 
>> а на реальных задачах получаются либо извращения (вроде специальные
>> VIEW'ы дабы DBIC в них смотрел и не пытался самостоятельничать), либо
>> те же запросы ручками
>> 
>> 
>> DBIC автоматизиреут наиболее частые простые задачи.
> 
> Наиболее частые простые задачи автоматизируются примитивнейшими sql-генераторами и не стоят того, чтоб иметь пиздец какой оверхед ( http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/03/benchmarking-dbixclass-vs-plain-dbi-on-hailo.html ). Если бенчмарки по ссылке устарели - покажите новые.
> 
> 
> Вы бы Айвара до конца читали. А там написано:
> 
> Even if it turns out that I'm doing everything right and there's no way to make DBIx::Class faster than this for Hailo I'd still like to look into using it. By converting to it I got rid of a lot of manual DBI tedium required to support multiple backends.
> 
> А самый последний абзац вообще говорит:
> 
> Aside from this speed issue my first impressions of DBIx::Class have been very positive. I'll probably use it for any future Perl code that accesses a database. Provided the application isn't an oddball like Hailo which isn't purely IO bound like most database-based programs.

Вы бы разделяли факты и суждения. Факт в том, что на его же тестах DBIC в 7 раз медленнее чистого DBI, а сколько там памяти дополнительной жрется - скромно умалчивается. И это все для того, чтобы автоматизировать простейшие задачи? Если для вас это приемлемо - тогда спорить бессмысленно :)

Про поддержку разных СУБД - это вообще нахер никому ненужный миф. Вы на больших проектах ее хоть раз меняли?

Евгений
jt на aaanet.ru


----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/192108d6/attachment.html>

From denis.fedoseev на gmail.com  Fri Oct 28 05:02:45 2011
From: denis.fedoseev на gmail.com (Denis Fedoseev)
Date: Fri, 28 Oct 2011 16:02:45 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?79TLzMDexc7JxSB3YXJuaW5ncyAndW5pbml0aWFs?=
	=?koi8-r?b?aXplZCc=?=
In-Reply-To: <CALE3dTWWdLiAjjvLbQ0F4njSoGuA_gOde+iLAZy4dOYM6nS_LQ@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<CALE3dTUiM6XuPGVFMuPVLVZb9hO2rZ4ff8JgMsBF4dT=BAyWCg@mail.gmail.com>
	<CANh0x-xLAFRa-LoPsL1-Vd7hVvi-mU05B64uqkKBmyuyDzSHQA@mail.gmail.com>
	<CALE3dTV8O=uGHQDnuyG7hnCnTU=RA27fD7TohEd1PeyW3acqPg@mail.gmail.com>
	<CALE3dTWWdLiAjjvLbQ0F4njSoGuA_gOde+iLAZy4dOYM6nS_LQ@mail.gmail.com>
Message-ID: <CALE3dTV_kSjQG0YAEZkK79UPJsA19H6ceXokOXE1TAphYVtbNA@mail.gmail.com>

Ну тут вопрос такой что пока скрипт на этапе разработки/тестирования там все
равно сыплется куча всего ибо дебаг и лучше видеть все. А когда все это уже
вышло в продакшен - то все равно обычно в логи никто не смотрит до момента
пока пользователь не примчит с воплем "аааааа, оно поломалося!", а дальше
включается режим дебага и все варнинги опять сыплются для устранения.
Т.е. мое мнение что в приложении которое крутится в продакшене они не нужны.

28.10.2011 15:36 пользователь "Ilya Chesnokov" <chesnokov.ilya на gmail.com>
написал:

28 октября 2011 г. 15:09 пользователь Denis Fedoseev
<denis.fedoseev на gmail.com> написал:

> Ну есть мнение, что баги ловятся тестами, а для дебага варнинги включить
не
> проблема.
Вопрос только, насколько это мнение совпадает с реальностью.
Другими словами -- если нет тестов или их недостаточно (а сколько это
-- достаточно?), то варнинги лучше не отключать?

На самом деле вопрос в том, что я на работе хочу отключить эти самые
warnings 'uninitialized', но в реале получается, что они действительно
бывают полезны для отлова некоторых косяков.

Собственно поэтому и хочу спросить мнения у тех, кто это уже сделал и
на основании их опыта вывести некую "формулу" -- набор достаточных
условий для отключения этих варнингов.


-- 
Best regards,
Ilya Chesnokov
-- 
Moscow.pm mailing list
moscow-pm на pm.org | http://moscow.pm.org...
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/de2cbe3c/attachment.html>

From rabbit+moscowpm на rabbit.us  Fri Oct 28 05:04:29 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 08:04:29 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <DA5EB15E-49FF-40B8-ADCF-DB0D1CCEF1D8@aaanet.ru>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
	<DA5EB15E-49FF-40B8-ADCF-DB0D1CCEF1D8@aaanet.ru>
Message-ID: <20111028120429.GA24610@rabbit.us>

On Fri, Oct 28, 2011 at 03:59:40PM +0400, Евгений Торопов wrote:
> 
> Про поддержку разных СУБД - это вообще нахер никому ненужный миф. Вы на больших проектах ее хоть раз меняли?

Одно слово - testing. Production и staging крутятся на шикарном СУБД. А у
разработчиков на каждом компе еквивалентный SQLite. И перескакивать с одного
на другое очен даже удобно.


From rabbit+moscowpm на rabbit.us  Fri Oct 28 05:07:03 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 08:07:03 -0400
Subject: [Moscow.pm] =?utf-8?b?0J7RgtC60LvRjtGH0LXQvdC40LUgd2FybmluZ3Mg?=
	=?utf-8?q?=27uninitialized=27?=
In-Reply-To: <CALE3dTV_kSjQG0YAEZkK79UPJsA19H6ceXokOXE1TAphYVtbNA@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<CALE3dTUiM6XuPGVFMuPVLVZb9hO2rZ4ff8JgMsBF4dT=BAyWCg@mail.gmail.com>
	<CANh0x-xLAFRa-LoPsL1-Vd7hVvi-mU05B64uqkKBmyuyDzSHQA@mail.gmail.com>
	<CALE3dTV8O=uGHQDnuyG7hnCnTU=RA27fD7TohEd1PeyW3acqPg@mail.gmail.com>
	<CALE3dTWWdLiAjjvLbQ0F4njSoGuA_gOde+iLAZy4dOYM6nS_LQ@mail.gmail.com>
	<CALE3dTV_kSjQG0YAEZkK79UPJsA19H6ceXokOXE1TAphYVtbNA@mail.gmail.com>
Message-ID: <20111028120703.GB24610@rabbit.us>

BOn Fri, Oct 28, 2011 at 04:02:45PM +0400, Denis Fedoseev wrote:
> Ну тут вопрос такой что пока скрипт на этапе разработки/тестирования там все
> равно сыплется куча всего ибо дебаг и лучше видеть все. А когда все это уже
> вышло в продакшен - то все равно обычно в логи никто не смотрит до момента
> пока пользователь не примчит с воплем "аааааа, оно поломалося!", а дальше
> включается режим дебага и все варнинги опять сыплются для устранения.
> Т.е. мое мнение что в приложении которое крутится в продакшене они не нужны.
> 

Если они посыпались в продакшн, а раньше их не было, то почти безусловно баги.
Лучше вариант (конечно вопрос спорный, и на любителя)
use warnings FATAL => 'all';

From jt на aaanet.ru  Fri Oct 28 05:07:42 2011
From: jt на aaanet.ru (=?utf-8?B?0JXQstCz0LXQvdC40Lkg0KLQvtGA0L7Qv9C+0LI=?=)
Date: Fri, 28 Oct 2011 16:07:42 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <20111028120429.GA24610@rabbit.us>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
	<DA5EB15E-49FF-40B8-ADCF-DB0D1CCEF1D8@aaanet.ru>
	<20111028120429.GA24610@rabbit.us>
Message-ID: <8579C0B9-62F0-43A4-844C-C329F179C09B@aaanet.ru>


On Oct 28, 2011, at 4:04 PM, Peter Rabbitson wrote:

> On Fri, Oct 28, 2011 at 03:59:40PM +0400, Евгений Торопов wrote:
>> 
>> Про поддержку разных СУБД - это вообще нахер никому ненужный миф. Вы на больших проектах ее хоть раз меняли?
> 
> Одно слово - testing. Production и staging крутятся на шикарном СУБД. А у
> разработчиков на каждом компе еквивалентный SQLite. И перескакивать с одного
> на другое очен даже удобно.

Тестовая и боевая среда должны быть полностью идентичны. Иначе "удобство" оборачивается дебагом на лайв серверах.

Евгений
jt на aaanet.ru

> 
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org


From rabbit+moscowpm на rabbit.us  Fri Oct 28 05:10:26 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 08:10:26 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <8579C0B9-62F0-43A4-844C-C329F179C09B@aaanet.ru>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
	<DA5EB15E-49FF-40B8-ADCF-DB0D1CCEF1D8@aaanet.ru>
	<20111028120429.GA24610@rabbit.us>
	<8579C0B9-62F0-43A4-844C-C329F179C09B@aaanet.ru>
Message-ID: <20111028121026.GC24610@rabbit.us>

On Fri, Oct 28, 2011 at 04:07:42PM +0400, Евгений Торопов wrote:
> 
> On Oct 28, 2011, at 4:04 PM, Peter Rabbitson wrote:
> 
> > On Fri, Oct 28, 2011 at 03:59:40PM +0400, Евгений Торопов wrote:
> >> 
> >> Про поддержку разных СУБД - это вообще нахер никому ненужный миф. Вы на больших проектах ее хоть раз меняли?
> > 
> > Одно слово - testing. Production и staging крутятся на шикарном СУБД. А у
> > разработчиков на каждом компе еквивалентный SQLite. И перескакивать с одного
> > на другое очен даже удобно.
> 
> Тестовая и боевая среда должны быть полностью идентичны. Иначе "удобство" оборачивается дебагом на лайв серверах.
> 

У тебя два понятю:
> Тестовая и боевая среда

У меня 3:
development (хren знает что на компах делатся и лежит)
staging (то что идентично с лайв, для полных тестов)
live

From jt на aaanet.ru  Fri Oct 28 05:14:37 2011
From: jt на aaanet.ru (=?utf-8?B?0JXQstCz0LXQvdC40Lkg0KLQvtGA0L7Qv9C+0LI=?=)
Date: Fri, 28 Oct 2011 16:14:37 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <20111028121026.GC24610@rabbit.us>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
	<DA5EB15E-49FF-40B8-ADCF-DB0D1CCEF1D8@aaanet.ru>
	<20111028120429.GA24610@rabbit.us>
	<8579C0B9-62F0-43A4-844C-C329F179C09B@aaanet.ru>
	<20111028121026.GC24610@rabbit.us>
Message-ID: <BCF390DD-3482-4FC4-B759-E76B78AE6FF7@aaanet.ru>



On Oct 28, 2011, at 4:10 PM, Peter Rabbitson wrote:

> On Fri, Oct 28, 2011 at 04:07:42PM +0400, Евгений Торопов wrote:
>> 
>> On Oct 28, 2011, at 4:04 PM, Peter Rabbitson wrote:
>> 
>>> On Fri, Oct 28, 2011 at 03:59:40PM +0400, Евгений Торопов wrote:
>>>> 
>>>> Про поддержку разных СУБД - это вообще нахер никому ненужный миф. Вы на больших проектах ее хоть раз меняли?
>>> 
>>> Одно слово - testing. Production и staging крутятся на шикарном СУБД. А у
>>> разработчиков на каждом компе еквивалентный SQLite. И перескакивать с одного
>>> на другое очен даже удобно.
>> 
>> Тестовая и боевая среда должны быть полностью идентичны. Иначе "удобство" оборачивается дебагом на лайв серверах.
>> 
> 
> У тебя два понятю:
>> Тестовая и боевая среда
> 
> У меня 3:
> development (хren знает что на компах делатся и лежит)
> staging (то что идентично с лайв, для полных тестов)
> live

Про хрен знает что вы мощно сказали :)

> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org


From andrei.protasovitski на gmail.com  Fri Oct 28 05:18:23 2011
From: andrei.protasovitski на gmail.com (Andrei)
Date: Fri, 28 Oct 2011 14:18:23 +0200
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <DA5EB15E-49FF-40B8-ADCF-DB0D1CCEF1D8@aaanet.ru>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
	<DA5EB15E-49FF-40B8-ADCF-DB0D1CCEF1D8@aaanet.ru>
Message-ID: <CANVWn7FPn__UuDTUaqioRsb77RjcbTdpkHA2+kTPAojHwBjykQ@mail.gmail.com>

28 октября 2011 г. 13:59 пользователь Евгений Торопов <jt на aaanet.ru>написал:

>
>
> On Oct 28, 2011, at 3:51 PM, Andrei wrote:
>
> 28 октября 2011 г. 13:35 пользователь Евгений Торопов <jt на aaanet.ru>написал:
>
>> On Oct 28, 2011, at 3:11 PM, Andrei wrote:
>>
>> 28 октября 2011 г. 13:08 пользователь Ivan Petrov <
>> i.petro.77.00 на gmail.com> написал:
>>
>>> > Твой аргумент какой то дикий - разница м/у DBIC и писать ручками SQL
>>> > подобна той между Perl и писать ручками assembler. Тебе Perl часом не
>>> > мешает?
>>>
>>> неуместное сравнение.
>>>
>>> говорить о DBIC vs писать SQL ручками вообще нельзя. ибо DBIC умеет
>>> составлять только самые простые запросы.
>>>
>>> а на реальных задачах получаются либо извращения (вроде специальные
>>> VIEW'ы дабы DBIC в них смотрел и не пытался самостоятельничать), либо
>>> те же запросы ручками
>>>
>>
>>
>> DBIC автоматизиреут наиболее частые простые задачи.
>>
>>
>> Наиболее частые простые задачи автоматизируются примитивнейшими
>> sql-генераторами и не стоят того, чтоб иметь пиздец какой оверхед (
>> http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/03/benchmarking-dbixclass-vs-plain-dbi-on-hailo.html ).
>> Если бенчмарки по ссылке устарели - покажите новые.
>>
>>
> Вы бы Айвара до конца читали. А там написано:
>
> Even if it turns out that I'm doing everything right and there's no way to
> make DBIx::Class faster than this for Hailo I'd still like to look into
> using it. By converting to it I got rid of a lot of manual DBI tedium
> required to support multiple backends.
>
> А самый последний абзац вообще говорит:
>
> Aside from this speed issue my first impressions of DBIx::Class have been
> very positive. I'll probably use it for any future Perl code that accesses a
> database. Provided the application isn't an oddball like Hailo which isn't
> purely IO bound like most database-based programs.
>
>
> Вы бы разделяли факты и суждения. Факт в том, что на его же тестах DBIC в 7
> раз медленнее чистого DBI, а сколько там памяти дополнительной жрется -
> скромно умалчивается. И это все для того, чтобы автоматизировать простейшие
> задачи? Если для вас это приемлемо - тогда спорить бессмысленно :)
>
> Про поддержку разных СУБД - это вообще нахер никому ненужный миф. Вы на
> больших проектах ее хоть раз меняли?
>


Вообще-то, тут имеется в виду "несколько БД", а не "разные СУБД". СУБД мы не
меняли, а вот БД разделяли, и именно использование ORM в этом случае сильно
помогает.

-- 
Andrei Protasovitski
< andrei[dot]protasovitski[at]gmail[dot]com >
Diemen, Netherlands
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/b8c85800/attachment-0001.html>

From dsimonov на gmail.com  Fri Oct 28 05:19:59 2011
From: dsimonov на gmail.com (Dmitry Simonov)
Date: Fri, 28 Oct 2011 16:19:59 +0400
Subject: [Moscow.pm] =?utf-8?b?0J7RgtC60LvRjtGH0LXQvdC40LUgd2FybmluZ3Mg?=
	=?utf-8?q?=27uninitialized=27?=
In-Reply-To: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
Message-ID: <CAL9wMxWDxVJhUOQQFs-m4LijsSU+OLDb2tKaKmLFtj4VSB+-kg@mail.gmail.com>

http://developers.rambler.ru/library/development/highload-basics/perl-rambler-mons/
Здесь упоминается об этой логике.

---
Dmitriy V. Simonov,
Perl & Python programmer



2011/10/28 Ilya Chesnokov <chesnokov.ilya на gmail.com>:
> Всем привет.
>
> Может быть глупый вопрос, но всё же интересно: какова мотивация того,
> что в модулях типа common::sense и uni::perl отключены предупреждения
> об "uninitialized value"?
>
> С одной стороны это понятно, да и в документации common::sense явно
> сказано:"undef is a well-defined feature of perl, and enabling
> warnings for using it rarely catches any bugs, but considerably limits
> you in what you can do" -- но реально хоть и редко, но баги всё же
> отлавливаются. Причём такие баги, о которых в противном случае можно
> было бы и не догадаться.
>
> Другими словами: на что надеются программисты, когда отключают эти
> предупреждения -- как ловят баги?
>
> --
> Best regards,
> Ilya Chesnokov
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>

From jt на aaanet.ru  Fri Oct 28 05:21:27 2011
From: jt на aaanet.ru (=?utf-8?B?0JXQstCz0LXQvdC40Lkg0KLQvtGA0L7Qv9C+0LI=?=)
Date: Fri, 28 Oct 2011 16:21:27 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <CANVWn7FPn__UuDTUaqioRsb77RjcbTdpkHA2+kTPAojHwBjykQ@mail.gmail.com>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
	<DA5EB15E-49FF-40B8-ADCF-DB0D1CCEF1D8@aaanet.ru>
	<CANVWn7FPn__UuDTUaqioRsb77RjcbTdpkHA2+kTPAojHwBjykQ@mail.gmail.com>
Message-ID: <974D6334-ECA7-4008-9001-60BF7261C709@aaanet.ru>


On Oct 28, 2011, at 4:18 PM, Andrei wrote:

> 28 октября 2011 г. 13:59 пользователь Евгений Торопов <jt на aaanet.ru> написал:
> 
> 
> On Oct 28, 2011, at 3:51 PM, Andrei wrote:
> 
>> 28 октября 2011 г. 13:35 пользователь Евгений Торопов <jt на aaanet.ru> написал:
>> On Oct 28, 2011, at 3:11 PM, Andrei wrote:
>> 
>>> 28 октября 2011 г. 13:08 пользователь Ivan Petrov <i.petro.77.00 на gmail.com> написал:
>>> > Твой аргумент какой то дикий - разница м/у DBIC и писать ручками SQL
>>> > подобна той между Perl и писать ручками assembler. Тебе Perl часом не
>>> > мешает?
>>> 
>>> неуместное сравнение.
>>> 
>>> говорить о DBIC vs писать SQL ручками вообще нельзя. ибо DBIC умеет
>>> составлять только самые простые запросы.
>>> 
>>> а на реальных задачах получаются либо извращения (вроде специальные
>>> VIEW'ы дабы DBIC в них смотрел и не пытался самостоятельничать), либо
>>> те же запросы ручками
>>> 
>>> 
>>> DBIC автоматизиреут наиболее частые простые задачи.
>> 
>> Наиболее частые простые задачи автоматизируются примитивнейшими sql-генераторами и не стоят того, чтоб иметь пиздец какой оверхед ( http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/03/benchmarking-dbixclass-vs-plain-dbi-on-hailo.html ). Если бенчмарки по ссылке устарели - покажите новые.
>> 
>> 
>> Вы бы Айвара до конца читали. А там написано:
>> 
>> Even if it turns out that I'm doing everything right and there's no way to make DBIx::Class faster than this for Hailo I'd still like to look into using it. By converting to it I got rid of a lot of manual DBI tedium required to support multiple backends.
>> 
>> А самый последний абзац вообще говорит:
>> 
>> Aside from this speed issue my first impressions of DBIx::Class have been very positive. I'll probably use it for any future Perl code that accesses a database. Provided the application isn't an oddball like Hailo which isn't purely IO bound like most database-based programs.
> 
> Вы бы разделяли факты и суждения. Факт в том, что на его же тестах DBIC в 7 раз медленнее чистого DBI, а сколько там памяти дополнительной жрется - скромно умалчивается. И это все для того, чтобы автоматизировать простейшие задачи? Если для вас это приемлемо - тогда спорить бессмысленно :)
> 
> Про поддержку разных СУБД - это вообще нахер никому ненужный миф. Вы на больших проектах ее хоть раз меняли?
> 
> 
> Вообще-то, тут имеется в виду "несколько БД", а не "разные СУБД". СУБД мы не меняли, а вот БД разделяли, и именно использование ORM в этом случае сильно помогает.

Хм, а как связаны между собой задачи БД-балансировки  и ORM? Или имеется ввиду что-то другое?

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/a7459506/attachment.html>

From rabbit+moscowpm на rabbit.us  Fri Oct 28 05:26:16 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 08:26:16 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <BCF390DD-3482-4FC4-B759-E76B78AE6FF7@aaanet.ru>
References: <20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
	<DA5EB15E-49FF-40B8-ADCF-DB0D1CCEF1D8@aaanet.ru>
	<20111028120429.GA24610@rabbit.us>
	<8579C0B9-62F0-43A4-844C-C329F179C09B@aaanet.ru>
	<20111028121026.GC24610@rabbit.us>
	<BCF390DD-3482-4FC4-B759-E76B78AE6FF7@aaanet.ru>
Message-ID: <20111028122615.GD24610@rabbit.us>

On Fri, Oct 28, 2011 at 04:14:37PM +0400, Евгений Торопов wrote:
> 
> 
> On Oct 28, 2011, at 4:10 PM, Peter Rabbitson wrote:
> 
> > On Fri, Oct 28, 2011 at 04:07:42PM +0400, Евгений Торопов wrote:
> >> 
> >> On Oct 28, 2011, at 4:04 PM, Peter Rabbitson wrote:
> >> 
> >>> On Fri, Oct 28, 2011 at 03:59:40PM +0400, Евгений Торопов wrote:
> >>>> 
> >>>> Про поддержку разных СУБД - это вообще нахер никому ненужный миф. Вы на больших проектах ее хоть раз меняли?
> >>> 
> >>> Одно слово - testing. Production и staging крутятся на шикарном СУБД. А у
> >>> разработчиков на каждом компе еквивалентный SQLite. И перескакивать с одного
> >>> на другое очен даже удобно.
> >> 
> >> Тестовая и боевая среда должны быть полностью идентичны. Иначе "удобство" оборачивается дебагом на лайв серверах.
> >> 
> > 
> > У тебя два понятю:
> >> Тестовая и боевая среда
> > 
> > У меня 3:
> > development (хren знает что на компах делатся и лежит)
> > staging (то что идентично с лайв, для полных тестов)
> > live
> 
> Про хрен знает что вы мощно сказали :)
> 

ХАХАХАХАХА

Ну и XREN! с ним :)

From andrei.protasovitski на gmail.com  Fri Oct 28 05:27:03 2011
From: andrei.protasovitski на gmail.com (Andrei)
Date: Fri, 28 Oct 2011 14:27:03 +0200
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <974D6334-ECA7-4008-9001-60BF7261C709@aaanet.ru>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
	<DA5EB15E-49FF-40B8-ADCF-DB0D1CCEF1D8@aaanet.ru>
	<CANVWn7FPn__UuDTUaqioRsb77RjcbTdpkHA2+kTPAojHwBjykQ@mail.gmail.com>
	<974D6334-ECA7-4008-9001-60BF7261C709@aaanet.ru>
Message-ID: <CANVWn7Fxrtnm_n8kv5T+bFBWq5MwF=GFjnBmWNn=VWAKNHyggw@mail.gmail.com>

28 октября 2011 г. 14:21 пользователь Евгений Торопов <jt на aaanet.ru>написал:

>
> Вы бы разделяли факты и суждения. Факт в том, что на его же тестах DBIC в 7
>> раз медленнее чистого DBI, а сколько там памяти дополнительной жрется -
>> скромно умалчивается. И это все для того, чтобы автоматизировать простейшие
>> задачи? Если для вас это приемлемо - тогда спорить бессмысленно :)
>>
>> Про поддержку разных СУБД - это вообще нахер никому ненужный миф. Вы на
>> больших проектах ее хоть раз меняли?
>>
>
>
> Вообще-то, тут имеется в виду "несколько БД", а не "разные СУБД". СУБД мы
> не меняли, а вот БД разделяли, и именно использование ORM в этом случае
> сильно помогает.
>
>
> Хм, а как связаны между собой задачи БД-балансировки  и ORM? Или имеется
> ввиду что-то другое?
>

Это не балансировка. Это когда раньше все данные лежали в одной схеме, а
потом оказалось, что их чересчур много и имеет смыл некоторые положить в
другую схему. В этом случае то, что раньше делалось со всякими JOIN'ами, в
новой реальности работать не будет, потому что схемы лежат в разных
коробках. И вот здесь наличие абстракции в виде ORM сильно помогает.

-- 
Andrei Protasovitski
< andrei[dot]protasovitski[at]gmail[dot]com >
Diemen, Netherlands
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/b625974f/attachment-0001.html>

From jt на aaanet.ru  Fri Oct 28 05:36:53 2011
From: jt на aaanet.ru (=?utf-8?B?0JXQstCz0LXQvdC40Lkg0KLQvtGA0L7Qv9C+0LI=?=)
Date: Fri, 28 Oct 2011 16:36:53 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <CANVWn7Fxrtnm_n8kv5T+bFBWq5MwF=GFjnBmWNn=VWAKNHyggw@mail.gmail.com>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
	<DA5EB15E-49FF-40B8-ADCF-DB0D1CCEF1D8@aaanet.ru>
	<CANVWn7FPn__UuDTUaqioRsb77RjcbTdpkHA2+kTPAojHwBjykQ@mail.gmail.com>
	<974D6334-ECA7-4008-9001-60BF7261C709@aaanet.ru>
	<CANVWn7Fxrtnm_n8kv5T+bFBWq5MwF=GFjnBmWNn=VWAKNHyggw@mail.gmail.com>
Message-ID: <A3B72A3F-A83A-4D52-83D8-AC3C261C5957@aaanet.ru>


On Oct 28, 2011, at 4:27 PM, Andrei wrote:

> 28 октября 2011 г. 14:21 пользователь Евгений Торопов <jt на aaanet.ru> написал:
> 
>> Вы бы разделяли факты и суждения. Факт в том, что на его же тестах DBIC в 7 раз медленнее чистого DBI, а сколько там памяти дополнительной жрется - скромно умалчивается. И это все для того, чтобы автоматизировать простейшие задачи? Если для вас это приемлемо - тогда спорить бессмысленно :)
>> 
>> Про поддержку разных СУБД - это вообще нахер никому ненужный миф. Вы на больших проектах ее хоть раз меняли?
>> 
>> 
>> Вообще-то, тут имеется в виду "несколько БД", а не "разные СУБД". СУБД мы не меняли, а вот БД разделяли, и именно использование ORM в этом случае сильно помогает.
> 
> Хм, а как связаны между собой задачи БД-балансировки  и ORM? Или имеется ввиду что-то другое?
> 
> Это не балансировка. Это когда раньше все данные лежали в одной схеме, а потом оказалось, что их чересчур много и имеет смыл некоторые положить в другую схему. В этом случае то, что раньше делалось со всякими JOIN'ами, в новой реальности работать не будет, потому что схемы лежат в разных коробках. И вот здесь наличие абстракции в виде ORM сильно помогает.

Понятненько, ну, для меня экономия на переписывании запросов все равно не аргумент. Если есть еще какие-то плюшки - было бы интересно узнать.


----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/1e9a176f/attachment.html>

From rabbit+moscowpm на rabbit.us  Fri Oct 28 05:46:24 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 08:46:24 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111028062003.GC20514@apache.rbscorp.ru>
References: <20111026162647.GF14585@apache.rbscorp.ru>
	<20111027172219.GA13125@rabbit.us>
	<20111027200530.GP14585@apache.rbscorp.ru>
	<20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
Message-ID: <20111028124623.GG24610@rabbit.us>

On Fri, Oct 28, 2011 at 10:20:06AM +0400, Ivan Petrov wrote:
> > ну уж не говоря о простом:
> 
> > имеем объект
> 
> > user
> 
> > у него есть отношение
> 
> > task
> 
> > $user->task->delete;
> 
> > далее
> > $user->is_changed == 0
> > $user->in_storage == 1
> 
> > отношения между объектами, говорите? где они?
> > ладно бы они были реализованы
> 
> > Отношение здесь $user->task.
> 
> > А какое поведение в этом случае ожидадлсь?
> 
> не все БД поддерживают FOREIGN. соответственно ожидалось что при
> удалении объекта отношения другой объект либо "молча" обновится (что
> должно быть управляемо), либо будет помечен как измененный.


Кстати я здесь не врубился в чем вопрос. Если:

Result::Task->has_many(user => 'Result::User', 'task_id', { cascade_delete => 1 });

то тогда да, $task->delete действительно выплюнет правильный ожидаеммый
DELETЕ (и так до конца по рекурсии). Однако (как и следует ожидать) с 
объектом $user ничего не произойдет, пока на нем не позовут
$user->discard_changes


From dmitry на karasik.eu.org  Fri Oct 28 05:56:10 2011
From: dmitry на karasik.eu.org (Dmitry Karasik)
Date: Fri, 28 Oct 2011 14:56:10 +0200
Subject: [Moscow.pm]
	=?koi8-r?b?79TLzMDexc7JxSB3YXJuaW5ncyAndW5pbml0aWFs?=
	=?koi8-r?b?aXplZCc=?=
In-Reply-To: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
Message-ID: <20111028125610.GA90815@tetsuo.karasik.eu.org>

On Fri, Oct 28, 2011 at 02:36:07PM +0400, Ilya Chesnokov wrote:
> Всем привет.
> 
> Может быть глупый вопрос, но всё же интересно: какова мотивация того,
> что в модулях типа common::sense и uni::perl отключены предупреждения
> об "uninitialized value"?

какой же это в баню common sense если с ним как минимум половина перлового народа
не согласны?

-- 
Sincerely,
	Dmitry Karasik


From mshogin на gmail.com  Fri Oct 28 06:02:20 2011
From: mshogin на gmail.com (=?KOI8-R?B?7cnIwcnMIPvPx8nO?=)
Date: Fri, 28 Oct 2011 17:02:20 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
	=?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <20111028114010.GV24610@rabbit.us>
References: <20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
	<CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
	<20111028112123.GR20514@apache.rbscorp.ru>
	<20111028112649.GS24610@rabbit.us>
	<20111028113008.GV20514@apache.rbscorp.ru>
	<20111028114010.GV24610@rabbit.us>
Message-ID: <CALzA1Mxwv2brHxvXTdjgk_wP4nzq-_VgP=C3w_rukQJ9rzifCQ@mail.gmail.com>

BBOn Fri, Oct 28, 2011 at 03:30:08PM +0400, Ivan Petrov wrote:
> > > Почему такой яростный упор на то что в DBIC что то не решается.
> Отслеживать
> > > состояние (state) смежных объетков не реализована в DBIC ибо
> >
> > отслеживать смежные объекты - не реализовано
>
> Ибо неуместно. Давай согласимся что здесь ты ожидаеш от DBIC чего то чего
> в нем в принципе быть не должно, даже теоретически
>
> > конструировать запросы - плохо реализовано - ибо хорошо нереализуемо
>
> Вот заладил... Давай посчитаем сколько раз тебя просили показать что
> собственно плохо:
>
> http://mail.pm.org/pipermail/moscow-pm/2011-October/010808.html
> http://mail.pm.org/pipermail/moscow-pm/2011-October/010810.html
> http://mail.pm.org/pipermail/moscow-pm/2011-October/010818.html
> http://mail.pm.org/pipermail/moscow-pm/2011-October/010824.html
> http://mail.pm.org/pipermail/moscow-pm/2011-October/010827.html
> http://mail.pm.org/pipermail/moscow-pm/2011-October/010849.html
> http://mail.pm.org/pipermail/moscow-pm/2011-October/010860.html
> http://mail.pm.org/pipermail/moscow-pm/2011-October/010873.html
>
> Я извиняюсь перед рассылкой что такой тарарам подняли. Явно толку
> не будет никакго. Я не буду больше отвечать на первый вопрос пока
> не появится код (если другие вопросы - буду рад ответить :)
>
>
У меня есть небольшой пример
( пример связан с ORM Django, думаю что на ORM Perl также распространяется )

Имеем след таблицу
create table entities (
 n number,
 title varchar2(100),
 dsc clob,
 status number,
 fd date
)

создаем индексы
create unique index ENTITIES$N on books ( n )
create index ENTITIES$N$STATUS on books ( n, status )

status - доступность сущности ( 0 - доступна , null - не доступна )

выбираем идентификаторы всех доступных сущностей

SQL
select en.n
  from entities en
where en.status = 0

план выполнения

 INDEX FAST FULL SCAN INDEX ENTITIES$N$STATUS

ORM
entities = Entity.objects.filter( status = 0 )

получится запрос
select en.*
  from entities en
where en.status = 0

план
TABLE ACCESS FULL

профит на лицо
+ ко всему прочему следует отметить что записи со status = null в индекс не
попадут, так что профит еще больше чем просто "на лицо"

Также можно построить индекс в который попадут только недоступные сущности и
выбирать используя этот индекс

Еще раз - извиняюсь за шум, и за товарища Петрова тоже
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
С уважением
Михаил Шогин.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/abce9912/attachment-0001.html>

From evdokimov.denis на gmail.com  Fri Oct 28 06:03:09 2011
From: evdokimov.denis на gmail.com (Denis Evdokimov)
Date: Fri, 28 Oct 2011 17:03:09 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
	=?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <CAKb9G9gFJhBrddvXm9hBwYcX2FPoEoyZLTLTj6haPwKEEB+42g@mail.gmail.com>
References: <CAKb9G9gFJhBrddvXm9hBwYcX2FPoEoyZLTLTj6haPwKEEB+42g@mail.gmail.com>
Message-ID: <CAFdXSm9eW-1qT4EkedWRVrTsdi0500g-FWF4J2FMU6xO5abZ+w@mail.gmail.com>

> Да и nginx блокируется много где: на чтении файлов, директорий,
> уменьшении картинок, генерации xslt
>
nginx не блокируется при чтении файлов и директорий.
Почему у вас nginx занимается уменьшением картинок и генерацией xslt?
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/04b84efc/attachment.html>

From zzz на zzz.org.ua  Fri Oct 28 06:04:07 2011
From: zzz на zzz.org.ua (Alexandr Gomoliako)
Date: Fri, 28 Oct 2011 16:04:07 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?79TLzMDexc7JxSB3YXJuaW5ncyAndW5pbml0aWFs?=
	=?koi8-r?b?aXplZCc=?=
In-Reply-To: <20111028125610.GA90815@tetsuo.karasik.eu.org>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<20111028125610.GA90815@tetsuo.karasik.eu.org>
Message-ID: <CAKb9G9j1LULY+dWGAveJEN5uOw46eg5Pdg2z03xj53p-f-erwQ@mail.gmail.com>

On 10/28/11, Dmitry Karasik <dmitry на karasik.eu.org> wrote:
> On Fri, Oct 28, 2011 at 02:36:07PM +0400, Ilya Chesnokov wrote:
>> Всем привет.
>>
>> Может быть глупый вопрос, но всё же интересно: какова мотивация того,
>> что в модулях типа common::sense и uni::perl отключены предупреждения
>> об "uninitialized value"?
>
> какой же это в баню common sense если с ним как минимум половина перлового
> народа не согласны?

А есть реальный аргумент против, кроме как другие не согласны?

From cub.uanic на gmail.com  Fri Oct 28 06:05:14 2011
From: cub.uanic на gmail.com (Oleg Kostyuk)
Date: Fri, 28 Oct 2011 16:05:14 +0300
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <CANVWn7Fxrtnm_n8kv5T+bFBWq5MwF=GFjnBmWNn=VWAKNHyggw@mail.gmail.com>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
	<DA5EB15E-49FF-40B8-ADCF-DB0D1CCEF1D8@aaanet.ru>
	<CANVWn7FPn__UuDTUaqioRsb77RjcbTdpkHA2+kTPAojHwBjykQ@mail.gmail.com>
	<974D6334-ECA7-4008-9001-60BF7261C709@aaanet.ru>
	<CANVWn7Fxrtnm_n8kv5T+bFBWq5MwF=GFjnBmWNn=VWAKNHyggw@mail.gmail.com>
Message-ID: <CAAPa60j4thXS_5Ez=wykOdi3+S2=0+KYS+oy65Zd2HL60jjmeg@mail.gmail.com>

А поделитесь, пожалуйста, практическим примером.

У меня буквально на днях возник проект в двумя схемами (Pg). Начал
думать как сделать - две dbic-шных схемы или одну? Мэтт на irc говорит
делай одну. Ну, в результате сделал примерно так:

lib/....../Schema/DB.pm
.......
__PACKAGE__->load_namespaces(
    result_namespace    => 'Class',
    resultset_namespace => 'ResultSet',
);
.......

Ну и далее всё в файлах lib/....../Schema/DB/Class/Data/*.pm и
lib/....../Schema/DB/Class/Public/*.pm - для схем data и public
соответственно. Чтоб не писать в table() имена таблиц с именем схемы
(а то мало ли - сегодня таблица в одной схеме, завтра в другой) -
использовал on_connect_do как описано в DBIx::Class::Storage::DBI::Pg.
К сожалению, проект свернули, практически сразу, потому я не знаю, что
из этого получилось бы в дальнейшем, и на сколько это вообще было бы
удобно на практике.

Потому собственно и вопрос - а как было у вас? Поделитесь.



28 октября 2011 г. 15:27 пользователь Andrei
<andrei.protasovitski на gmail.com> написал:
> 28 октября 2011 г. 14:21 пользователь Евгений Торопов <jt на aaanet.ru>
> написал:
>>
>>> Вы бы разделяли факты и суждения. Факт в том, что на его же тестах DBIC в
>>> 7 раз медленнее чистого DBI, а сколько там памяти дополнительной жрется -
>>> скромно умалчивается. И это все для того, чтобы автоматизировать простейшие
>>> задачи? Если для вас это приемлемо - тогда спорить бессмысленно :)
>>> Про поддержку разных СУБД - это вообще нахер никому ненужный миф. Вы на
>>> больших проектах ее хоть раз меняли?
>>
>> Вообще-то, тут имеется в виду "несколько БД", а не "разные СУБД". СУБД мы
>> не меняли, а вот БД разделяли, и именно использование ORM в этом случае
>> сильно помогает.
>>
>> Хм, а как связаны между собой задачи БД-балансировки  и ORM? Или имеется
>> ввиду что-то другое?
>
> Это не балансировка. Это когда раньше все данные лежали в одной схеме, а
> потом оказалось, что их чересчур много и имеет смыл некоторые положить в
> другую схему. В этом случае то, что раньше делалось со всякими JOIN'ами, в
> новой реальности работать не будет, потому что схемы лежат в разных
> коробках. И вот здесь наличие абстракции в виде ORM сильно помогает.
>
> --
> Andrei Protasovitski
> < andrei[dot]protasovitski[at]gmail[dot]com >
> Diemen, Netherlands
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>



-- 
Sincerely yours,
Oleg Kostyuk (CUB-UANIC)

From zzz на zzz.org.ua  Fri Oct 28 06:08:04 2011
From: zzz на zzz.org.ua (Alexandr Gomoliako)
Date: Fri, 28 Oct 2011 16:08:04 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
	=?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <CAFdXSm9eW-1qT4EkedWRVrTsdi0500g-FWF4J2FMU6xO5abZ+w@mail.gmail.com>
References: <CAKb9G9gFJhBrddvXm9hBwYcX2FPoEoyZLTLTj6haPwKEEB+42g@mail.gmail.com>
	<CAFdXSm9eW-1qT4EkedWRVrTsdi0500g-FWF4J2FMU6xO5abZ+w@mail.gmail.com>
Message-ID: <CAKb9G9iNOqUuw319Usmj7bz-_i=B0Z3r361xkibK+Gj=2bZz7w@mail.gmail.com>

On 10/28/11, Denis Evdokimov <evdokimov.denis на gmail.com> wrote:
> nginx не блокируется при чтении файлов и директорий.

Блокируется. AIO по дефолту выключено.

From i.petro.77.00 на gmail.com  Fri Oct 28 06:09:52 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 17:09:52 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <CALzA1Mxwv2brHxvXTdjgk_wP4nzq-_VgP=C3w_rukQJ9rzifCQ@mail.gmail.com>
References: <CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
	<CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
	<20111028112123.GR20514@apache.rbscorp.ru>
	<20111028112649.GS24610@rabbit.us>
	<20111028113008.GV20514@apache.rbscorp.ru>
	<20111028114010.GV24610@rabbit.us>
	<CALzA1Mxwv2brHxvXTdjgk_wP4nzq-_VgP=C3w_rukQJ9rzifCQ@mail.gmail.com>
Message-ID: <20111028130951.GX20514@apache.rbscorp.ru>

> ORM
> entities = Entity.objects.filter( status = 0 )

тут столбики надо перечислить которые выбираешь

только при этом "брюки превращаются. превращаются брюки..." (ц)

From mshogin на gmail.com  Fri Oct 28 06:14:55 2011
From: mshogin на gmail.com (=?KOI8-R?B?7cnIwcnMIPvPx8nO?=)
Date: Fri, 28 Oct 2011 17:14:55 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
	=?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <20111028130951.GX20514@apache.rbscorp.ru>
References: <CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
	<CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
	<20111028112123.GR20514@apache.rbscorp.ru>
	<20111028112649.GS24610@rabbit.us>
	<20111028113008.GV20514@apache.rbscorp.ru>
	<20111028114010.GV24610@rabbit.us>
	<CALzA1Mxwv2brHxvXTdjgk_wP4nzq-_VgP=C3w_rukQJ9rzifCQ@mail.gmail.com>
	<20111028130951.GX20514@apache.rbscorp.ru>
Message-ID: <CALzA1MwwGinDgdpCtDR_8qxHsEvvdjh2=t81uhsDs0xq52y2kA@mail.gmail.com>

>
> > ORM
> > entities = Entity.objects.filter( status = 0 )
>
> тут столбики надо перечислить которые выбираешь
>
>
Ну если можно перечислить столбики, снимаю свой пример :))

"Век живи - век учись! и ты наконец достигнешь того, что, подобно мудрецу,
будешь иметь право сказать, что ничего не знаешь" (с)


> только при этом "брюки превращаются. превращаются брюки..." (ц)
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
С уважением
Михаил Шогин.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/dfb941fd/attachment-0001.html>

From dmitry на karasik.eu.org  Fri Oct 28 06:16:46 2011
From: dmitry на karasik.eu.org (Dmitry Karasik)
Date: Fri, 28 Oct 2011 15:16:46 +0200
Subject: [Moscow.pm]
	=?koi8-r?b?79TLzMDexc7JxSB3YXJuaW5ncyAndW5pbml0aWFs?=
	=?koi8-r?b?aXplZCc=?=
In-Reply-To: <CAKb9G9j1LULY+dWGAveJEN5uOw46eg5Pdg2z03xj53p-f-erwQ@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<20111028125610.GA90815@tetsuo.karasik.eu.org>
	<CAKb9G9j1LULY+dWGAveJEN5uOw46eg5Pdg2z03xj53p-f-erwQ@mail.gmail.com>
Message-ID: <20111028131646.GA91478@tetsuo.karasik.eu.org>

> >> Может быть глупый вопрос, но всё же интересно: какова мотивация того,
> >> что в модулях типа common::sense и uni::perl отключены предупреждения
> >> об "uninitialized value"?
> > какой же это в баню common sense если с ним как минимум половина перлового
> > народа не согласны?
> А есть реальный аргумент против, кроме как другие не согласны?

В ответах уже проскакивал например, что баги ловит - я согласен. Вопрос наоборот,
какие есть не аргументы "против", а аргументы "за"? Т.е. да, undef в конструкциях типа 
$hash{undef}++ был бы даже элегантен, но раз уж в перле так не сложилось, то 
воодить такой синтаксис хоть и можно, но бэк-портить замучаешься..

-- 
Sincerely,
	Dmitry Karasik


From andrei.protasovitski на gmail.com  Fri Oct 28 06:17:23 2011
From: andrei.protasovitski на gmail.com (Andrei)
Date: Fri, 28 Oct 2011 15:17:23 +0200
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <CALzA1Mxwv2brHxvXTdjgk_wP4nzq-_VgP=C3w_rukQJ9rzifCQ@mail.gmail.com>
References: <20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
	<CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
	<20111028112123.GR20514@apache.rbscorp.ru>
	<20111028112649.GS24610@rabbit.us>
	<20111028113008.GV20514@apache.rbscorp.ru>
	<20111028114010.GV24610@rabbit.us>
	<CALzA1Mxwv2brHxvXTdjgk_wP4nzq-_VgP=C3w_rukQJ9rzifCQ@mail.gmail.com>
Message-ID: <CANVWn7FNdDhySqh8-MmGaUpQwgVK9esZgvnNGiVcGs6+d4iYnQ@mail.gmail.com>

28 октября 2011 г. 15:02 пользователь Михаил Шогин <mshogin на gmail.com>написал:

> У меня есть небольшой пример
> ( пример связан с ORM Django, думаю что на ORM Perl также распространяется
> )
>
> Имеем след таблицу
> create table entities (
>  n number,
>  title varchar2(100),
>  dsc clob,
>  status number,
>  fd date
> )
>
> создаем индексы
> create unique index ENTITIES$N on books ( n )
> create index ENTITIES$N$STATUS on books ( n, status )
>
> status - доступность сущности ( 0 - доступна , null - не доступна )
>

Объясните, пожалуйста, разработчикам, что null означает "отсутсвие данных",
только "отсутсвие данных" и ничего, кроме "отсутствия данных". Разработчики,
работающие с базами данных, должны понимать, что "отсутсвие данных" не может
быть использовано как "данные".

В этом конкретном случае "запись недоступна" есть некоторые вполне
определённые данные, и для этого статуса должно быть определено полне
конкретное значение.


>  выбираем идентификаторы всех доступных сущностей
>
> SQL
> select en.n
>   from entities en
> where en.status = 0
>
> план выполнения
>
>  INDEX FAST FULL SCAN INDEX ENTITIES$N$STATUS
>
> ORM
> entities = Entity.objects.filter( status = 0 )
>

Про указание колонок уже упомянули.


> получится запрос
> select en.*
>   from entities en
> where en.status = 0
>
> план
> TABLE ACCESS FULL
>
> профит на лицо
> + ко всему прочему следует отметить что записи со status = null в индекс не
> попадут, так что профит еще больше чем просто "на лицо"
>
> Также можно построить индекс в который попадут только недоступные сущности
> и выбирать используя этот индекс
>
>

-- 
Andrei Protasovitski
< andrei[dot]protasovitski[at]gmail[dot]com >
Diemen, Netherlands
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/e144db2b/attachment.html>

From zzz на zzz.org.ua  Fri Oct 28 06:22:44 2011
From: zzz на zzz.org.ua (Alexandr Gomoliako)
Date: Fri, 28 Oct 2011 16:22:44 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?79TLzMDexc7JxSB3YXJuaW5ncyAndW5pbml0aWFs?=
	=?koi8-r?b?aXplZCc=?=
In-Reply-To: <20111028131646.GA91478@tetsuo.karasik.eu.org>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<20111028125610.GA90815@tetsuo.karasik.eu.org>
	<CAKb9G9j1LULY+dWGAveJEN5uOw46eg5Pdg2z03xj53p-f-erwQ@mail.gmail.com>
	<20111028131646.GA91478@tetsuo.karasik.eu.org>
Message-ID: <CAKb9G9im_L6bLS-EF7rDFqpmX-keNxgvsCvUfG7GftESEE8WVw@mail.gmail.com>

On 10/28/11, Dmitry Karasik <dmitry на karasik.eu.org> wrote:
>> >> Может быть глупый вопрос, но всё же интересно: какова мотивация того,
>> >> что в модулях типа common::sense и uni::perl отключены предупреждения
>> >> об "uninitialized value"?
>> > какой же это в баню common sense если с ним как минимум половина
>> > перлового
>> > народа не согласны?
>> А есть реальный аргумент против, кроме как другие не согласны?
>

> В ответах уже проскакивал например, что баги ловит - я согласен.

Про баги это неправда. Я уже почти год пользуюсь с выключенными
uninitialized, никаких проблем.

> какие есть не аргументы "против", а аргументы "за"?

Чистота кода. Пример:
    if ($r->{foo} > 100)
вместо
    if ($r->{foo} =~ /^\d+$/ && $r->{foo} > 100)

Аналогично с кучей ненужных инициализаций, вложенными хэшам и т.д.
В целом читабельность повышается очень сильно.

From zzz на zzz.org.ua  Fri Oct 28 06:26:58 2011
From: zzz на zzz.org.ua (Alexandr Gomoliako)
Date: Fri, 28 Oct 2011 16:26:58 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?79TLzMDexc7JxSB3YXJuaW5ncyAndW5pbml0aWFs?=
	=?koi8-r?b?aXplZCc=?=
In-Reply-To: <CAKb9G9im_L6bLS-EF7rDFqpmX-keNxgvsCvUfG7GftESEE8WVw@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<20111028125610.GA90815@tetsuo.karasik.eu.org>
	<CAKb9G9j1LULY+dWGAveJEN5uOw46eg5Pdg2z03xj53p-f-erwQ@mail.gmail.com>
	<20111028131646.GA91478@tetsuo.karasik.eu.org>
	<CAKb9G9im_L6bLS-EF7rDFqpmX-keNxgvsCvUfG7GftESEE8WVw@mail.gmail.com>
Message-ID: <CAKb9G9gGx4mkemjLyJXLZY8irKnZtC1zLiet8zCyqr2i0PNv7g@mail.gmail.com>

On 10/28/11, Alexandr Gomoliako <zzz на zzz.org.ua> wrote:
> вместо
>     if ($r->{foo} =~ /^\d+$/ && $r->{foo} > 100)

Я тут наверное даже мало написал, уже забыл:
     if (defined $r->{foo} && $r->{foo} =~ /^\d+$/ && $r->{foo} > 100)

From evdokimov.denis на gmail.com  Fri Oct 28 06:29:31 2011
From: evdokimov.denis на gmail.com (Denis Evdokimov)
Date: Fri, 28 Oct 2011 17:29:31 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?79TLzMDexc7JxSB3YXJuaW5ncyAndW5pbml0aWFs?=
	=?koi8-r?b?aXplZCc=?=
In-Reply-To: <CAKb9G9gGx4mkemjLyJXLZY8irKnZtC1zLiet8zCyqr2i0PNv7g@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<20111028125610.GA90815@tetsuo.karasik.eu.org>
	<CAKb9G9j1LULY+dWGAveJEN5uOw46eg5Pdg2z03xj53p-f-erwQ@mail.gmail.com>
	<20111028131646.GA91478@tetsuo.karasik.eu.org>
	<CAKb9G9im_L6bLS-EF7rDFqpmX-keNxgvsCvUfG7GftESEE8WVw@mail.gmail.com>
	<CAKb9G9gGx4mkemjLyJXLZY8irKnZtC1zLiet8zCyqr2i0PNv7g@mail.gmail.com>
Message-ID: <CAFdXSm-bVJUzYSBaMShvLrXgm3oFmXh9mPC1mHBSZM8kjMgmJg@mail.gmail.com>

Может всё-таки
if ($r->{foo} && $r->{foo} > 100)


28 октября 2011 г. 17:26 пользователь Alexandr Gomoliako
<zzz на zzz.org.ua>написал:

> On 10/28/11, Alexandr Gomoliako <zzz на zzz.org.ua> wrote:
> > вместо
> >     if ($r->{foo} =~ /^\d+$/ && $r->{foo} > 100)
>
> Я тут наверное даже мало написал, уже забыл:
>     if (defined $r->{foo} && $r->{foo} =~ /^\d+$/ && $r->{foo} > 100)
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/a2c057fe/attachment-0001.html>

From zzz на zzz.org.ua  Fri Oct 28 06:32:48 2011
From: zzz на zzz.org.ua (Alexandr Gomoliako)
Date: Fri, 28 Oct 2011 16:32:48 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?79TLzMDexc7JxSB3YXJuaW5ncyAndW5pbml0aWFs?=
	=?koi8-r?b?aXplZCc=?=
In-Reply-To: <CAFdXSm-bVJUzYSBaMShvLrXgm3oFmXh9mPC1mHBSZM8kjMgmJg@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<20111028125610.GA90815@tetsuo.karasik.eu.org>
	<CAKb9G9j1LULY+dWGAveJEN5uOw46eg5Pdg2z03xj53p-f-erwQ@mail.gmail.com>
	<20111028131646.GA91478@tetsuo.karasik.eu.org>
	<CAKb9G9im_L6bLS-EF7rDFqpmX-keNxgvsCvUfG7GftESEE8WVw@mail.gmail.com>
	<CAKb9G9gGx4mkemjLyJXLZY8irKnZtC1zLiet8zCyqr2i0PNv7g@mail.gmail.com>
	<CAFdXSm-bVJUzYSBaMShvLrXgm3oFmXh9mPC1mHBSZM8kjMgmJg@mail.gmail.com>
Message-ID: <CAKb9G9gUbC-KFJFpc1UHAM6tKXmedSZv9sFmphp_-Ai2VnhFpQ@mail.gmail.com>

On 10/28/11, Denis Evdokimov <evdokimov.denis на gmail.com> wrote:
> Может всё-таки
> if ($r->{foo} && $r->{foo} > 100)

Нет, это будет ругаться на не int.
И не будет, если включить common sense.

From rabbit+moscowpm на rabbit.us  Fri Oct 28 06:34:30 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 09:34:30 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <CALzA1Mxwv2brHxvXTdjgk_wP4nzq-_VgP=C3w_rukQJ9rzifCQ@mail.gmail.com>
References: <CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
	<CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
	<20111028112123.GR20514@apache.rbscorp.ru>
	<20111028112649.GS24610@rabbit.us>
	<20111028113008.GV20514@apache.rbscorp.ru>
	<20111028114010.GV24610@rabbit.us>
	<CALzA1Mxwv2brHxvXTdjgk_wP4nzq-_VgP=C3w_rukQJ9rzifCQ@mail.gmail.com>
Message-ID: <20111028133430.GH24610@rabbit.us>

On Fri, Oct 28, 2011 at 05:02:20PM +0400, Михаил Шогин wrote:
> ( пример связан с ORM Django, думаю что на ORM Perl также распространяется )

Нету зверя "ORM Perl". Как и во всем другом с Perl связаным есть много разных
решений. Вот товарищ Петров (за которого извиняюсь) скоро еще одно решение
выложит.

> 
> Имеем след таблицу
> create table entities (
>  n number,
>  title varchar2(100),
>  dsc clob,
>  status number,
>  fd date
> )
> 
> создаем индексы
> create unique index ENTITIES$N on books ( n )
> create index ENTITIES$N$STATUS on books ( n, status )
> 
> выбираем идентификаторы всех доступных сущностей
> 
> получится запрос
> select en.*
>   from entities en
> where en.status = 0
> 
> план
> TABLE ACCESS FULL
> 

Я знаком с DBIC, ROSEDB, FEY - ни один из них никогда не запросит
SELECT x.*. Не только "можно указать колонки", но еще по умолчанию
все колонки поименно ORM назовет. Скорее более громоздко спросить
буквально SELECT x.*, чем любой другой вариант.

From evdokimov.denis на gmail.com  Fri Oct 28 06:34:57 2011
From: evdokimov.denis на gmail.com (Denis Evdokimov)
Date: Fri, 28 Oct 2011 17:34:57 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?79TLzMDexc7JxSB3YXJuaW5ncyAndW5pbml0aWFs?=
	=?koi8-r?b?aXplZCc=?=
In-Reply-To: <CAKb9G9gUbC-KFJFpc1UHAM6tKXmedSZv9sFmphp_-Ai2VnhFpQ@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<20111028125610.GA90815@tetsuo.karasik.eu.org>
	<CAKb9G9j1LULY+dWGAveJEN5uOw46eg5Pdg2z03xj53p-f-erwQ@mail.gmail.com>
	<20111028131646.GA91478@tetsuo.karasik.eu.org>
	<CAKb9G9im_L6bLS-EF7rDFqpmX-keNxgvsCvUfG7GftESEE8WVw@mail.gmail.com>
	<CAKb9G9gGx4mkemjLyJXLZY8irKnZtC1zLiet8zCyqr2i0PNv7g@mail.gmail.com>
	<CAFdXSm-bVJUzYSBaMShvLrXgm3oFmXh9mPC1mHBSZM8kjMgmJg@mail.gmail.com>
	<CAKb9G9gUbC-KFJFpc1UHAM6tKXmedSZv9sFmphp_-Ai2VnhFpQ@mail.gmail.com>
Message-ID: <CAFdXSm-fKLySgpH8DUHB9fW5Ous4N5KrT4x+-9p7-aBf5K6_4Q@mail.gmail.com>

> Нет, это будет ругаться на не int.
> И не будет, если включить common sense.
>
> По моему это очень правильно, что будет.
Или это в порядке вещей хранить разные сущности в одном месте.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/7414560d/attachment.html>

From chesnokov.ilya на gmail.com  Fri Oct 28 06:35:54 2011
From: chesnokov.ilya на gmail.com (Ilya Chesnokov)
Date: Fri, 28 Oct 2011 17:35:54 +0400
Subject: [Moscow.pm] =?utf-8?b?0J7RgtC60LvRjtGH0LXQvdC40LUgd2FybmluZ3Mg?=
	=?utf-8?q?=27uninitialized=27?=
In-Reply-To: <CAKb9G9im_L6bLS-EF7rDFqpmX-keNxgvsCvUfG7GftESEE8WVw@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<20111028125610.GA90815@tetsuo.karasik.eu.org>
	<CAKb9G9j1LULY+dWGAveJEN5uOw46eg5Pdg2z03xj53p-f-erwQ@mail.gmail.com>
	<20111028131646.GA91478@tetsuo.karasik.eu.org>
	<CAKb9G9im_L6bLS-EF7rDFqpmX-keNxgvsCvUfG7GftESEE8WVw@mail.gmail.com>
Message-ID: <CANh0x-zETOK1OWo5aVR8XE=840P_ZSiBKDO1JnY8rsJdBdd0eg@mail.gmail.com>

28 октября 2011 г. 17:22 пользователь Alexandr Gomoliako
<zzz на zzz.org.ua> написал:
>> В ответах уже проскакивал например, что баги ловит - я согласен.
>
> Про баги это неправда. Я уже почти год пользуюсь с выключенными
> uninitialized, никаких проблем.

Это как в той цитате с баша про вирусы:

(звонок админу городской сети):
- у вас вирусы по локалке гуляют!
- достали вы со своим Касперским, поставьте нод, он их не видит!

Банальный пример полезности предупреждения об uninitialized value
(заодно и пожалуюсь).

Недавно Яндекс.Деньги и изменили регистр символа в уведомлении о
принятом платеже.
В результате в хеше параметров значением $p->{CustomerNumber} был
undef -- и при подсчёте контрольной суммы она не сходилась с
эталонной, и мы не принимали платёж. Это продолжалось некоторое время,
после чего проблему обнаружили и исправили.

На следующий же день пришло автоматическое письмо со списком
варнингов, случившихся за прошедший день, в числе которых был и этот
варнинг с "use of uninitialized value" в ключе хеша.

Если бы у нас не было относительно много платежей по Яндекс.Деньгам в
течение дня, и мы не заметили бы эту проблему раньше, то вполне
возможно, заметили бы её только на следующий день -- когда увидели бы
её в списке варнингов. Если же 'use of uninitialized value' было бы
отключено, могли бы очень долго не замечать этот баг.

>> какие есть не аргументы "против", а аргументы "за"?
>
> Чистота кода. Пример:
>    if ($r->{foo} > 100)
> вместо
>    if ($r->{foo} =~ /^\d+$/ && $r->{foo} > 100)

тут скорее: if ( $r->{foo} && $r->{foo} > 100 )

> Аналогично с кучей ненужных инициализаций, вложенными хэшам и т.д.
> В целом читабельность повышается очень сильно.
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
Best regards,
Ilya Chesnokov

From mshogin на gmail.com  Fri Oct 28 06:37:00 2011
From: mshogin на gmail.com (=?KOI8-R?B?7cnIwcnMIPvPx8nO?=)
Date: Fri, 28 Oct 2011 17:37:00 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
	=?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <CANVWn7FNdDhySqh8-MmGaUpQwgVK9esZgvnNGiVcGs6+d4iYnQ@mail.gmail.com>
References: <20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
	<CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
	<20111028112123.GR20514@apache.rbscorp.ru>
	<20111028112649.GS24610@rabbit.us>
	<20111028113008.GV20514@apache.rbscorp.ru>
	<20111028114010.GV24610@rabbit.us>
	<CALzA1Mxwv2brHxvXTdjgk_wP4nzq-_VgP=C3w_rukQJ9rzifCQ@mail.gmail.com>
	<CANVWn7FNdDhySqh8-MmGaUpQwgVK9esZgvnNGiVcGs6+d4iYnQ@mail.gmail.com>
Message-ID: <CALzA1MwbaxNhzwALE-SbepLeUD0Qj8e78bOVgF7w4-LgnixQ3w@mail.gmail.com>

>
> 28 октября 2011 г. 15:02 пользователь Михаил Шогин <mshogin на gmail.com>написал:
>
>> У меня есть небольшой пример
>> ( пример связан с ORM Django, думаю что на ORM Perl также распространяется
>> )
>>
>> Имеем след таблицу
>> create table entities (
>>  n number,
>>  title varchar2(100),
>>  dsc clob,
>>  status number,
>>  fd date
>> )
>>
>> создаем индексы
>> create unique index ENTITIES$N on books ( n )
>> create index ENTITIES$N$STATUS on books ( n, status )
>>
>> status - доступность сущности ( 0 - доступна , null - не доступна )
>>
>
> Объясните, пожалуйста, разработчикам, что null означает "отсутсвие данных",
> только "отсутсвие данных" и ничего, кроме "отсутствия данных". Разработчики,
> работающие с базами данных, должны понимать, что "отсутсвие данных" не может
> быть использовано как "данные".
>
> В этом конкретном случае "запись недоступна" есть некоторые вполне
> определённые данные, и для этого статуса должно быть определено полне
> конкретное значение.
>
NULL - тоже значение.

Объяснение простое,
Поле выставляется в значение NULL для не попадания в индекс.

Согласен что было бы лучше сделать так
status - доступность сущности ( 1 - доступна , 0 - не доступна )

однако в таком случае пришлось бы строить индекс

create index ENTITIES$N$STATUSACTIVE on books (n, case when status = 1 then
1 else null end )

но в таком случае, для того что бы пойти по индексу, придется использовать
запрос вида

select en.n
  from entities en
where case
               when en.status = 1
               then 1
               else null
          end  = 1

как такое сделать используя ORM, я честно не знаю



>
>>  выбираем идентификаторы всех доступных сущностей
>>
>> SQL
>> select en.n
>>   from entities en
>> where en.status = 0
>>
>> план выполнения
>>
>>  INDEX FAST FULL SCAN INDEX ENTITIES$N$STATUS
>>
>> ORM
>> entities = Entity.objects.filter( status = 0 )
>>
>
> Про указание колонок уже упомянули.
>
Да, уже отписал по этому поводу

>
>
>> получится запрос
>> select en.*
>>   from entities en
>> where en.status = 0
>>
>> план
>> TABLE ACCESS FULL
>>
>> профит на лицо
>> + ко всему прочему следует отметить что записи со status = null в индекс
>> не попадут, так что профит еще больше чем просто "на лицо"
>>
>> Также можно построить индекс в который попадут только недоступные сущности
>> и выбирать используя этот индекс
>>
>>
>
> --
> Andrei Protasovitski
> < andrei[dot]protasovitski[at]gmail[dot]com >
> Diemen, Netherlands
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>


-- 
С уважением
Михаил Шогин.
Tel: +7 915 0311328
ICQ: 266776394
e-mail: shogin на corp.mail.ru
Интернет холдинг @mail.ru
www.mail.ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/e73161c9/attachment-0001.html>

From zzz на zzz.org.ua  Fri Oct 28 06:38:22 2011
From: zzz на zzz.org.ua (Alexandr Gomoliako)
Date: Fri, 28 Oct 2011 16:38:22 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?79TLzMDexc7JxSB3YXJuaW5ncyAndW5pbml0aWFs?=
	=?koi8-r?b?aXplZCc=?=
In-Reply-To: <CAFdXSm-fKLySgpH8DUHB9fW5Ous4N5KrT4x+-9p7-aBf5K6_4Q@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<20111028125610.GA90815@tetsuo.karasik.eu.org>
	<CAKb9G9j1LULY+dWGAveJEN5uOw46eg5Pdg2z03xj53p-f-erwQ@mail.gmail.com>
	<20111028131646.GA91478@tetsuo.karasik.eu.org>
	<CAKb9G9im_L6bLS-EF7rDFqpmX-keNxgvsCvUfG7GftESEE8WVw@mail.gmail.com>
	<CAKb9G9gGx4mkemjLyJXLZY8irKnZtC1zLiet8zCyqr2i0PNv7g@mail.gmail.com>
	<CAFdXSm-bVJUzYSBaMShvLrXgm3oFmXh9mPC1mHBSZM8kjMgmJg@mail.gmail.com>
	<CAKb9G9gUbC-KFJFpc1UHAM6tKXmedSZv9sFmphp_-Ai2VnhFpQ@mail.gmail.com>
	<CAFdXSm-fKLySgpH8DUHB9fW5Ous4N5KrT4x+-9p7-aBf5K6_4Q@mail.gmail.com>
Message-ID: <CAKb9G9jqd2affshOA3HDkfSzCsFS4aY+K5i2c1ZKevhN03NTbA@mail.gmail.com>

On 10/28/11, Denis Evdokimov <evdokimov.denis на gmail.com> wrote:
> По моему это очень правильно, что будет.
> Или это в порядке вещей хранить разные сущности в одном месте.

Конечно в порядке вещей, скаляры могут хранить и строки, и инты,
и флоаты, и какие-то магические значения.

Это же все то, ради чего перл и используют.

From rabbit+moscowpm на rabbit.us  Fri Oct 28 06:41:11 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 09:41:11 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <CALzA1MwbaxNhzwALE-SbepLeUD0Qj8e78bOVgF7w4-LgnixQ3w@mail.gmail.com>
References: <05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
	<CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
	<20111028112123.GR20514@apache.rbscorp.ru>
	<20111028112649.GS24610@rabbit.us>
	<20111028113008.GV20514@apache.rbscorp.ru>
	<20111028114010.GV24610@rabbit.us>
	<CALzA1Mxwv2brHxvXTdjgk_wP4nzq-_VgP=C3w_rukQJ9rzifCQ@mail.gmail.com>
	<CANVWn7FNdDhySqh8-MmGaUpQwgVK9esZgvnNGiVcGs6+d4iYnQ@mail.gmail.com>
	<CALzA1MwbaxNhzwALE-SbepLeUD0Qj8e78bOVgF7w4-LgnixQ3w@mail.gmail.com>
Message-ID: <20111028134111.GJ24610@rabbit.us>

On Fri, Oct 28, 2011 at 05:37:00PM +0400, Михаил Шогин wrote:
> >
> > 28 октября 2011 г. 15:02 пользователь Михаил Шогин <mshogin на gmail.com>написал:
> >
> >> У меня есть небольшой пример
> >> ( пример связан с ORM Django, думаю что на ORM Perl также распространяется
> >> )
> >>
> >> Имеем след таблицу
> >> create table entities (
> >>  n number,
> >>  title varchar2(100),
> >>  dsc clob,
> >>  status number,
> >>  fd date
> >> )
> >>
> >> создаем индексы
> >> create unique index ENTITIES$N on books ( n )
> >> create index ENTITIES$N$STATUS on books ( n, status )
> >>
> >> status - доступность сущности ( 0 - доступна , null - не доступна )
> >>
> >
> > Объясните, пожалуйста, разработчикам, что null означает "отсутсвие данных",
> > только "отсутсвие данных" и ничего, кроме "отсутствия данных". Разработчики,
> > работающие с базами данных, должны понимать, что "отсутсвие данных" не может
> > быть использовано как "данные".
> >
> > В этом конкретном случае "запись недоступна" есть некоторые вполне
> > определённые данные, и для этого статуса должно быть определено полне
> > конкретное значение.
> >
> NULL - тоже значение.
> 
> Объяснение простое,
> Поле выставляется в значение NULL для не попадания в индекс.
> 
> Согласен что было бы лучше сделать так
> status - доступность сущности ( 1 - доступна , 0 - не доступна )
> 
> однако в таком случае пришлось бы строить индекс
> 
> create index ENTITIES$N$STATUSACTIVE on books (n, case when status = 1 then
> 1 else null end )
> 
> но в таком случае, для того что бы пойти по индексу, придется использовать
> запрос вида
> 
> select en.n
>   from entities en
> where case
>                when en.status = 1
>                then 1
>                else null
>           end  = 1
> 
> как такое сделать используя ORM, я честно не знаю

Сделать можно... но ЗАЧЕМ?! Чем недостаточен

SELECT en.n FROM entities en WHERE en.status = 1


From mshogin на gmail.com  Fri Oct 28 06:41:30 2011
From: mshogin на gmail.com (=?KOI8-R?B?7cnIwcnMIPvPx8nO?=)
Date: Fri, 28 Oct 2011 17:41:30 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
	=?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <20111028133430.GH24610@rabbit.us>
References: <CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
	<CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
	<20111028112123.GR20514@apache.rbscorp.ru>
	<20111028112649.GS24610@rabbit.us>
	<20111028113008.GV20514@apache.rbscorp.ru>
	<20111028114010.GV24610@rabbit.us>
	<CALzA1Mxwv2brHxvXTdjgk_wP4nzq-_VgP=C3w_rukQJ9rzifCQ@mail.gmail.com>
	<20111028133430.GH24610@rabbit.us>
Message-ID: <CALzA1MytDwYQgXYFqyAnd_fb8w1YAEo8m_NNuU9scKAR+-NhFA@mail.gmail.com>

>
> On Fri, Oct 28, 2011 at 05:02:20PM +0400, Михаил Шогин wrote:
> > ( пример связан с ORM Django, думаю что на ORM Perl также
> распространяется )
>
> Нету зверя "ORM Perl". Как и во всем другом с Perl связаным есть много
> разных
> решений. Вот товарищ Петров (за которого извиняюсь) скоро еще одно решение
> выложит.


Согласен, но конкретизировать  что либо  из этого
http://search.cpan.org/search?m=all&q=ORM
не имею возможности, не знаком с этим многообразием.


>
> Я знаком с DBIC, ROSEDB, FEY - ни один из них никогда не запросит
> SELECT x.*. Не только "можно указать колонки", но еще по умолчанию
> все колонки поименно ORM назовет. Скорее более громоздко спросить
> буквально SELECT x.*, чем любой другой вариант.
>

Да, спасибо, уже прочитал

--
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
С уважением
Михаил Шогин.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/66ac3e71/attachment.html>

From evdokimov.denis на gmail.com  Fri Oct 28 06:42:40 2011
From: evdokimov.denis на gmail.com (Denis Evdokimov)
Date: Fri, 28 Oct 2011 17:42:40 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?79TLzMDexc7JxSB3YXJuaW5ncyAndW5pbml0aWFs?=
	=?koi8-r?b?aXplZCc=?=
In-Reply-To: <CAKb9G9jqd2affshOA3HDkfSzCsFS4aY+K5i2c1ZKevhN03NTbA@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<20111028125610.GA90815@tetsuo.karasik.eu.org>
	<CAKb9G9j1LULY+dWGAveJEN5uOw46eg5Pdg2z03xj53p-f-erwQ@mail.gmail.com>
	<20111028131646.GA91478@tetsuo.karasik.eu.org>
	<CAKb9G9im_L6bLS-EF7rDFqpmX-keNxgvsCvUfG7GftESEE8WVw@mail.gmail.com>
	<CAKb9G9gGx4mkemjLyJXLZY8irKnZtC1zLiet8zCyqr2i0PNv7g@mail.gmail.com>
	<CAFdXSm-bVJUzYSBaMShvLrXgm3oFmXh9mPC1mHBSZM8kjMgmJg@mail.gmail.com>
	<CAKb9G9gUbC-KFJFpc1UHAM6tKXmedSZv9sFmphp_-Ai2VnhFpQ@mail.gmail.com>
	<CAFdXSm-fKLySgpH8DUHB9fW5Ous4N5KrT4x+-9p7-aBf5K6_4Q@mail.gmail.com>
	<CAKb9G9jqd2affshOA3HDkfSzCsFS4aY+K5i2c1ZKevhN03NTbA@mail.gmail.com>
Message-ID: <CAFdXSm9g-T6hzW1hSJx20hosKOjfd0ut3-8Q60tH-Fk83nXN+w@mail.gmail.com>

> Конечно в порядке вещей, скаляры могут хранить и строки, и инты,
> и флоаты, и какие-то магические значения.
>
> Это же все то, ради чего перл и используют.
>

Правильно ли я Вас понимаю, что

$r->{cnt} = "bla-bla-bla";
...
if ( $r->{cnt} > 100 )

Нормальная ситуация и ругаться не стоит?
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/a339e254/attachment.html>

From chesnokov.ilya на gmail.com  Fri Oct 28 06:44:45 2011
From: chesnokov.ilya на gmail.com (Ilya Chesnokov)
Date: Fri, 28 Oct 2011 17:44:45 +0400
Subject: [Moscow.pm] =?utf-8?b?0J7RgtC60LvRjtGH0LXQvdC40LUgd2FybmluZ3Mg?=
	=?utf-8?q?=27uninitialized=27?=
In-Reply-To: <CAL9wMxWDxVJhUOQQFs-m4LijsSU+OLDb2tKaKmLFtj4VSB+-kg@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<CAL9wMxWDxVJhUOQQFs-m4LijsSU+OLDb2tKaKmLFtj4VSB+-kg@mail.gmail.com>
Message-ID: <CANh0x-xF4-92d1KPBKvoVpw7Sk6nV5sUS8K35qd-ErvbbwZOQA@mail.gmail.com>

28 октября 2011 г. 16:19 пользователь Dmitry Simonov
<dsimonov на gmail.com> написал:
> http://developers.rambler.ru/library/development/highload-basics/perl-rambler-mons/
> Здесь упоминается об этой логике.

Есть большая разница между "я заинтерполировал пробел в строке" и
"какая-то редиска прислала неверные данные, не предупредив заранее, в
результате чего вылез варнинг". Во втором случае без варнинга никуда.
Лучше, конечно, всегда как-то проверять входные данные (кстати!) -- но
покажите мне того, кто это всегда делает (равно как и того, кто имеет
полный набор тестов на каждый чих).

-- 
Best regards,
Ilya Chesnokov

From chesnokov.ilya на gmail.com  Fri Oct 28 06:45:48 2011
From: chesnokov.ilya на gmail.com (Ilya Chesnokov)
Date: Fri, 28 Oct 2011 17:45:48 +0400
Subject: [Moscow.pm] =?utf-8?b?0J7RgtC60LvRjtGH0LXQvdC40LUgd2FybmluZ3Mg?=
	=?utf-8?q?=27uninitialized=27?=
In-Reply-To: <CANh0x-xF4-92d1KPBKvoVpw7Sk6nV5sUS8K35qd-ErvbbwZOQA@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<CAL9wMxWDxVJhUOQQFs-m4LijsSU+OLDb2tKaKmLFtj4VSB+-kg@mail.gmail.com>
	<CANh0x-xF4-92d1KPBKvoVpw7Sk6nV5sUS8K35qd-ErvbbwZOQA@mail.gmail.com>
Message-ID: <CANh0x-wwYS4Ufj-xuzoKvaDM+MFgZzLBRgPwb7iHUndnNCY8nw@mail.gmail.com>

28 октября 2011 г. 17:44 пользователь Ilya Chesnokov
<chesnokov.ilya на gmail.com> написал:
> 28 октября 2011 г. 16:19 пользователь Dmitry Simonov
> <dsimonov на gmail.com> написал:
>> http://developers.rambler.ru/library/development/highload-basics/perl-rambler-mons/
>> Здесь упоминается об этой логике.
>
> Есть большая разница между "я заинтерполировал пробел в строке" и

Заинтерполировал undef, простите.


-- 
Best regards,
Ilya Chesnokov

From chesnokov.ilya на gmail.com  Fri Oct 28 06:52:45 2011
From: chesnokov.ilya на gmail.com (Ilya Chesnokov)
Date: Fri, 28 Oct 2011 17:52:45 +0400
Subject: [Moscow.pm] =?utf-8?b?0J7RgtC60LvRjtGH0LXQvdC40LUgd2FybmluZ3Mg?=
	=?utf-8?q?=27uninitialized=27?=
In-Reply-To: <20111028114917.GY24610@rabbit.us>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<CALE3dTUiM6XuPGVFMuPVLVZb9hO2rZ4ff8JgMsBF4dT=BAyWCg@mail.gmail.com>
	<CANh0x-xLAFRa-LoPsL1-Vd7hVvi-mU05B64uqkKBmyuyDzSHQA@mail.gmail.com>
	<20111028114917.GY24610@rabbit.us>
Message-ID: <CANh0x-yHG9Y+4xygW3SVLm9-sfZNCdabJAsLHBON0Vt3V8su5A@mail.gmail.com>

28 октября 2011 г. 15:49 пользователь Peter Rabbitson
<rabbit+moscowpm на rabbit.us> написал:
> On Fri, Oct 28, 2011 at 03:36:34PM +0400, Ilya Chesnokov wrote:
>> На самом деле вопрос в том, что я на работе хочу отключить эти самые
>> warnings 'uninitialized', но в реале получается, что они действительно
>> бывают полезны для отлова некоторых косяков.
>
> А можно поинтерисоватся зачем? Оверхед у strict/warnings практически
> отсуствует (все реализованно в Sv флагах, которые переключаются *вне
> зависимости* от того будет perl шипеть или нет).

В принципе, манит грешный путь, который пропагандирует Alexandr Gomoliako.
"Красивый" код, меньше "букаф", вроде бы всё более удобно и гламурно.

Поэтому и хотелось бы узнать мнение тех людей, которые отключают
warnings 'uninitialized' -- например, Шарифулина и Монса -- не боитесь
ли вы пропустить какую-нибудь ошибку, отключив эти варнинги? И что в
вас в таком случае вселяет уверенность в том, что вы не пропустите
какой-нибудь важный баг?

-- 
Best regards,
Ilya Chesnokov

From zzz на zzz.org.ua  Fri Oct 28 06:54:12 2011
From: zzz на zzz.org.ua (Alexandr Gomoliako)
Date: Fri, 28 Oct 2011 16:54:12 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?79TLzMDexc7JxSB3YXJuaW5ncyAndW5pbml0aWFs?=
	=?koi8-r?b?aXplZCc=?=
In-Reply-To: <CAFdXSm9g-T6hzW1hSJx20hosKOjfd0ut3-8Q60tH-Fk83nXN+w@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<20111028125610.GA90815@tetsuo.karasik.eu.org>
	<CAKb9G9j1LULY+dWGAveJEN5uOw46eg5Pdg2z03xj53p-f-erwQ@mail.gmail.com>
	<20111028131646.GA91478@tetsuo.karasik.eu.org>
	<CAKb9G9im_L6bLS-EF7rDFqpmX-keNxgvsCvUfG7GftESEE8WVw@mail.gmail.com>
	<CAKb9G9gGx4mkemjLyJXLZY8irKnZtC1zLiet8zCyqr2i0PNv7g@mail.gmail.com>
	<CAFdXSm-bVJUzYSBaMShvLrXgm3oFmXh9mPC1mHBSZM8kjMgmJg@mail.gmail.com>
	<CAKb9G9gUbC-KFJFpc1UHAM6tKXmedSZv9sFmphp_-Ai2VnhFpQ@mail.gmail.com>
	<CAFdXSm-fKLySgpH8DUHB9fW5Ous4N5KrT4x+-9p7-aBf5K6_4Q@mail.gmail.com>
	<CAKb9G9jqd2affshOA3HDkfSzCsFS4aY+K5i2c1ZKevhN03NTbA@mail.gmail.com>
	<CAFdXSm9g-T6hzW1hSJx20hosKOjfd0ut3-8Q60tH-Fk83nXN+w@mail.gmail.com>
Message-ID: <CAKb9G9hGteuxWYxx-e=cO9NdHyoRbL4j2z1RqjnuL8pKYSNdnw@mail.gmail.com>

On 10/28/11, Denis Evdokimov <evdokimov.denis на gmail.com> wrote:
> Правильно ли я Вас понимаю, что
>
> $r->{cnt} = "bla-bla-bla";
> ...
> if ( $r->{cnt} > 100 )
>
> Нормальная ситуация и ругаться не стоит?

Да.

On 10/28/11, Ilya Chesnokov <chesnokov.ilya на gmail.com> wrote:
> Недавно Яндекс.Деньги и изменили регистр символа в уведомлении о
> принятом платеже.

И не сказали? Странно.

Проверяйте данные, когда считаете чексумму и пишите в лог причину,
почему она не прошла.
Это же может быть как undef, так и другой формат какого-то поля.

From rabbit+moscowpm на rabbit.us  Fri Oct 28 06:59:38 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 09:59:38 -0400
Subject: [Moscow.pm] =?utf-8?b?0J7RgtC60LvRjtGH0LXQvdC40LUgd2FybmluZ3Mg?=
	=?utf-8?q?=27uninitialized=27?=
In-Reply-To: <CANh0x-yHG9Y+4xygW3SVLm9-sfZNCdabJAsLHBON0Vt3V8su5A@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<CALE3dTUiM6XuPGVFMuPVLVZb9hO2rZ4ff8JgMsBF4dT=BAyWCg@mail.gmail.com>
	<CANh0x-xLAFRa-LoPsL1-Vd7hVvi-mU05B64uqkKBmyuyDzSHQA@mail.gmail.com>
	<20111028114917.GY24610@rabbit.us>
	<CANh0x-yHG9Y+4xygW3SVLm9-sfZNCdabJAsLHBON0Vt3V8su5A@mail.gmail.com>
Message-ID: <20111028135938.GL24610@rabbit.us>

On Fri, Oct 28, 2011 at 05:52:45PM +0400, Ilya Chesnokov wrote:
> 28 октября 2011 г. 15:49 пользователь Peter Rabbitson
> <rabbit+moscowpm на rabbit.us> написал:
> > On Fri, Oct 28, 2011 at 03:36:34PM +0400, Ilya Chesnokov wrote:
> >> На самом деле вопрос в том, что я на работе хочу отключить эти самые
> >> warnings 'uninitialized', но в реале получается, что они действительно
> >> бывают полезны для отлова некоторых косяков.
> >
> > А можно поинтерисоватся зачем? Оверхед у strict/warnings практически
> > отсуствует (все реализованно в Sv флагах, которые переключаются *вне
> > зависимости* от того будет perl шипеть или нет).
> 
> В принципе, манит грешный путь, который пропагандирует Alexandr Gomoliako.
> "Красивый" код, меньше "букаф", вроде бы всё более удобно и гламурно.
> 
> Поэтому и хотелось бы узнать мнение тех людей, которые отключают
> warnings 'uninitialized' -- например, Шарифулина и Монса -- не боитесь
> ли вы пропустить какую-нибудь ошибку, отключив эти варнинги? И что в
> вас в таком случае вселяет уверенность в том, что вы не пропустите
> какой-нибудь важный баг?

Все зависит от риска. Например:

LogInfo "User id $id not found"

Если $id undef - ну кинет оно warning ну и Хren! с ним :)



Однако если есть код

File::Path::rmtree("$HOME/$tempdir")

и $tempdir undef... :)

From zzz на zzz.org.ua  Fri Oct 28 07:02:33 2011
From: zzz на zzz.org.ua (Alexandr Gomoliako)
Date: Fri, 28 Oct 2011 17:02:33 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?79TLzMDexc7JxSB3YXJuaW5ncyAndW5pbml0aWFs?=
	=?koi8-r?b?aXplZCc=?=
In-Reply-To: <20111028135938.GL24610@rabbit.us>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<CALE3dTUiM6XuPGVFMuPVLVZb9hO2rZ4ff8JgMsBF4dT=BAyWCg@mail.gmail.com>
	<CANh0x-xLAFRa-LoPsL1-Vd7hVvi-mU05B64uqkKBmyuyDzSHQA@mail.gmail.com>
	<20111028114917.GY24610@rabbit.us>
	<CANh0x-yHG9Y+4xygW3SVLm9-sfZNCdabJAsLHBON0Vt3V8su5A@mail.gmail.com>
	<20111028135938.GL24610@rabbit.us>
Message-ID: <CAKb9G9j=LGwhwsLMoOpCRQgoP=M4L6wwBVq8SmRB2Rv_7ZCe3A@mail.gmail.com>

On 10/28/11, Peter Rabbitson <rabbit+moscowpm на rabbit.us> wrote:
> Все зависит от риска.

Точно, никто же не забирает undef у вас. Все так же можно проверить
    defined $foo

From i.petro.77.00 на gmail.com  Fri Oct 28 06:22:27 2011
From: i.petro.77.00 на gmail.com (Ivan Petrov)
Date: Fri, 28 Oct 2011 17:22:27 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <CALzA1MwwGinDgdpCtDR_8qxHsEvvdjh2=t81uhsDs0xq52y2kA@mail.gmail.com>
References: <05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
	<CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
	<20111028112123.GR20514@apache.rbscorp.ru>
	<20111028112649.GS24610@rabbit.us>
	<20111028113008.GV20514@apache.rbscorp.ru>
	<20111028114010.GV24610@rabbit.us>
	<CALzA1Mxwv2brHxvXTdjgk_wP4nzq-_VgP=C3w_rukQJ9rzifCQ@mail.gmail.com>
	<20111028130951.GX20514@apache.rbscorp.ru>
	<CALzA1MwwGinDgdpCtDR_8qxHsEvvdjh2=t81uhsDs0xq52y2kA@mail.gmail.com>
Message-ID: <20111028132227.GZ20514@apache.rbscorp.ru>


> "Век живи - век учись! и ты наконец достигнешь того, что, подобно мудрецу,
> будешь иметь право сказать, что ничего не знаешь" (с)

я хотел сказать, что извратнувшись можно получить таки тот же запрос.
но вопрос тут в том что 
a. на извращения тратится куда больше телодвижений нежели на написание
запроса
b. о запросе мы все равно думаем пока эту выборку делаем,
соответственно "абстракция не работает"


From mshogin на gmail.com  Fri Oct 28 07:17:09 2011
From: mshogin на gmail.com (=?KOI8-R?B?7cnIwcnMIPvPx8nO?=)
Date: Fri, 28 Oct 2011 18:17:09 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
	=?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <20111028132227.GZ20514@apache.rbscorp.ru>
References: <05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
	<CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
	<20111028112123.GR20514@apache.rbscorp.ru>
	<20111028112649.GS24610@rabbit.us>
	<20111028113008.GV20514@apache.rbscorp.ru>
	<20111028114010.GV24610@rabbit.us>
	<CALzA1Mxwv2brHxvXTdjgk_wP4nzq-_VgP=C3w_rukQJ9rzifCQ@mail.gmail.com>
	<20111028130951.GX20514@apache.rbscorp.ru>
	<CALzA1MwwGinDgdpCtDR_8qxHsEvvdjh2=t81uhsDs0xq52y2kA@mail.gmail.com>
	<20111028132227.GZ20514@apache.rbscorp.ru>
Message-ID: <CALzA1MzesF7EW0Lq1QmzYeAxJtT7cRYt9npNwDabCwwBMF9y0w@mail.gmail.com>

28 октября 2011 г. 17:22 пользователь Ivan Petrov
<i.petro.77.00 на gmail.com>написал:

>
> > "Век живи - век учись! и ты наконец достигнешь того, что, подобно
> мудрецу,
> > будешь иметь право сказать, что ничего не знаешь" (с)
>
Эта цитата касательно меня. Не знал что можно перечислять выбираемые столбцы
)


> я хотел сказать, что извратнувшись можно получить таки тот же запрос.
> но вопрос тут в том что
> a. на извращения тратится куда больше телодвижений нежели на написание
> запроса
>
Обычная практика создания небольшого индекса на большом объеме данных.
Однако согласен что использование партиций более уместно в этом случае.

b. о запросе мы все равно думаем пока эту выборку делаем,
> соответственно "абстракция не работает"
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
С уважением
Михаил Шогин.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/7f0dab57/attachment-0001.html>

From mi на ya.ru  Fri Oct 28 07:18:26 2011
From: mi на ya.ru (Nikolay Mishin)
Date: Fri, 28 Oct 2011 18:18:26 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?79TLzMDexc7JxSB3YXJuaW5ncyAndW5pbml0aWFs?=
	=?koi8-r?b?aXplZCc=?=
In-Reply-To: <CAKb9G9gGx4mkemjLyJXLZY8irKnZtC1zLiet8zCyqr2i0PNv7g@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<20111028125610.GA90815@tetsuo.karasik.eu.org>
	<CAKb9G9j1LULY+dWGAveJEN5uOw46eg5Pdg2z03xj53p-f-erwQ@mail.gmail.com>
	<20111028131646.GA91478@tetsuo.karasik.eu.org>
	<CAKb9G9im_L6bLS-EF7rDFqpmX-keNxgvsCvUfG7GftESEE8WVw@mail.gmail.com>
	<CAKb9G9gGx4mkemjLyJXLZY8irKnZtC1zLiet8zCyqr2i0PNv7g@mail.gmail.com>
Message-ID: <531319811506@web53.yandex.ru>

А почему не так


use 5.01;
use Carp;
my %filials;
$filials{foo} = 300;

#$filials{boo} = 200;
my $ref_hash = \%filials;
my @test     = qw/a 2 d 300 ffd 22/;

#test_var($ref_hash);

for $test_val (@test) {
    $filials{foo} = $test_val;
    test_var( \%filials );
    say $test_val;
}

sub test_var {
    my $r = shift;
    croak("Value ***$r->{foo}*** is not defined or not number")
      if !defined $r->{foo} || $r->{foo} != ~/^\d+$/;

    if ( $r->{foo} > 100 ) {
        say '$r->{foo} > 100';
    }

}

и тогда , если будет ошибка. ты не будешь ломать головку - и где из моих 1000 строк кода она может быть?

28.10.2011, 17:26, "Alexandr Gomoliako" <zzz на zzz.org.ua>:
> On 10/28/11, Alexandr Gomoliako <zzz на zzz.org.ua> wrote:
>
>>  вместо
>>      if ($r->{foo} =~ /^\d+$/ && $r->{foo} > 100)
>
> Я тут наверное даже мало написал, уже забыл:
>      if (defined $r->{foo} && $r->{foo} =~ /^\d+$/ && $r->{foo} > 100)
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

--
Nikolay Mishin

From mi на ya.ru  Fri Oct 28 07:23:07 2011
From: mi на ya.ru (Nikolay Mishin)
Date: Fri, 28 Oct 2011 18:23:07 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?79TLzMDexc7JxSB3YXJuaW5ncyAndW5pbml0aWFs?=
	=?koi8-r?b?aXplZCc=?=
In-Reply-To: <531319811506@web53.yandex.ru>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<20111028125610.GA90815@tetsuo.karasik.eu.org>
	<CAKb9G9j1LULY+dWGAveJEN5uOw46eg5Pdg2z03xj53p-f-erwQ@mail.gmail.com>
	<20111028131646.GA91478@tetsuo.karasik.eu.org>
	<CAKb9G9im_L6bLS-EF7rDFqpmX-keNxgvsCvUfG7GftESEE8WVw@mail.gmail.com>
	<CAKb9G9gGx4mkemjLyJXLZY8irKnZtC1zLiet8zCyqr2i0PNv7g@mail.gmail.com>
	<531319811506@web53.yandex.ru>
Message-ID: <490891319811787@web28.yandex.ru>

сорри (исправленный вариант)


use 5.01;
use Carp;
my %filials;
$filials{foo} = 300;
my $ref_hash = \%filials;
my @test     = qw/444 33a 2 d 300 ffd 22/;

for $test_val (@test) {
    $filials{foo} = $test_val;
    test_var( \%filials );
    say $test_val;
}

sub test_var {
    my $r = shift;
    croak("Value ***$r->{foo}*** is not defined or not number")
      if !defined $r->{foo} || $r->{foo} !~ /^\d+$/;

    if ( $r->{foo} > 100 ) {
        say '$r->{foo} > 100';
    }

}


28.10.2011, 18:18, "Nikolay Mishin" <mi на ya.ru>:
> А почему не так
>
> use 5.01;
> use Carp;
> my %filials;
> $filials{foo} = 300;
>
> #$filials{boo} = 200;
> my $ref_hash = \%filials;
> my @test     = qw/a 2 d 300 ffd 22/;
>
> #test_var($ref_hash);
>
> for $test_val (@test) {
>     $filials{foo} = $test_val;
>     test_var( \%filials );
>     say $test_val;
> }
>
> sub test_var {
>     my $r = shift;
>     croak("Value ***$r->{foo}*** is not defined or not number")
>       if !defined $r->{foo} || $r->{foo} != ~/^\d+$/;
>
>     if ( $r->{foo} > 100 ) {
>         say '$r->{foo} > 100';
>     }
>
> }
>
> и тогда , если будет ошибка. ты не будешь ломать головку - и где из моих 1000 строк кода она может быть?
>
> 28.10.2011, 17:26, "Alexandr Gomoliako" <zzz на zzz.org.ua>:
>
>>  On 10/28/11, Alexandr Gomoliako <zzz на zzz.org.ua> wrote:
>>>   вместо
>>>       if ($r->{foo} =~ /^\d+$/ && $r->{foo} > 100)
>>  Я тут наверное даже мало написал, уже забыл:
>>       if (defined $r->{foo} && $r->{foo} =~ /^\d+$/ && $r->{foo} > 100)
>>
>>  --
>>  Moscow.pm mailing list
>>  moscow-pm на pm.org | http://moscow.pm.org
>
> --
> Nikolay Mishin
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

--
Nikolay Mishin

From nikzubkov на gmail.com  Fri Oct 28 07:24:05 2011
From: nikzubkov на gmail.com (Nikita Zubkov)
Date: Fri, 28 Oct 2011 18:24:05 +0400
Subject: [Moscow.pm] =?utf-8?b?0J7RgtC60LvRjtGH0LXQvdC40LUgd2FybmluZ3Mg?=
	=?utf-8?q?=27uninitialized=27?=
In-Reply-To: <CANh0x-yHG9Y+4xygW3SVLm9-sfZNCdabJAsLHBON0Vt3V8su5A@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<CALE3dTUiM6XuPGVFMuPVLVZb9hO2rZ4ff8JgMsBF4dT=BAyWCg@mail.gmail.com>
	<CANh0x-xLAFRa-LoPsL1-Vd7hVvi-mU05B64uqkKBmyuyDzSHQA@mail.gmail.com>
	<20111028114917.GY24610@rabbit.us>
	<CANh0x-yHG9Y+4xygW3SVLm9-sfZNCdabJAsLHBON0Vt3V8su5A@mail.gmail.com>
Message-ID: <CAA4UdcTZLqb7HBZiyhkicJXCnNVedLXiJp71roq68Gb=k2Rcxg@mail.gmail.com>

Главная проблема у warnings 'uninitialized' и других схожих - огромное
количество "ложных" срабатываний.

28 октября 2011 г. 17:52 пользователь Ilya Chesnokov
<chesnokov.ilya на gmail.com> написал:
> 28 октября 2011 г. 15:49 пользователь Peter Rabbitson
> <rabbit+moscowpm на rabbit.us> написал:
>> On Fri, Oct 28, 2011 at 03:36:34PM +0400, Ilya Chesnokov wrote:
>>> На самом деле вопрос в том, что я на работе хочу отключить эти самые
>>> warnings 'uninitialized', но в реале получается, что они действительно
>>> бывают полезны для отлова некоторых косяков.
>>
>> А можно поинтерисоватся зачем? Оверхед у strict/warnings практически
>> отсуствует (все реализованно в Sv флагах, которые переключаются *вне
>> зависимости* от того будет perl шипеть или нет).
>
> В принципе, манит грешный путь, который пропагандирует Alexandr Gomoliako.
> "Красивый" код, меньше "букаф", вроде бы всё более удобно и гламурно.
>
> Поэтому и хотелось бы узнать мнение тех людей, которые отключают
> warnings 'uninitialized' -- например, Шарифулина и Монса -- не боитесь
> ли вы пропустить какую-нибудь ошибку, отключив эти варнинги? И что в
> вас в таком случае вселяет уверенность в том, что вы не пропустите
> какой-нибудь важный баг?
>
> --
> Best regards,
> Ilya Chesnokov
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
С уважением,
Никита Зубков
тел: +7 (915) 082-76-80

From andrei.protasovitski на gmail.com  Fri Oct 28 07:28:38 2011
From: andrei.protasovitski на gmail.com (Andrei)
Date: Fri, 28 Oct 2011 16:28:38 +0200
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <CAAPa60j4thXS_5Ez=wykOdi3+S2=0+KYS+oy65Zd2HL60jjmeg@mail.gmail.com>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
	<DA5EB15E-49FF-40B8-ADCF-DB0D1CCEF1D8@aaanet.ru>
	<CANVWn7FPn__UuDTUaqioRsb77RjcbTdpkHA2+kTPAojHwBjykQ@mail.gmail.com>
	<974D6334-ECA7-4008-9001-60BF7261C709@aaanet.ru>
	<CANVWn7Fxrtnm_n8kv5T+bFBWq5MwF=GFjnBmWNn=VWAKNHyggw@mail.gmail.com>
	<CAAPa60j4thXS_5Ez=wykOdi3+S2=0+KYS+oy65Zd2HL60jjmeg@mail.gmail.com>
Message-ID: <CANVWn7FVbpz-a6gpy+jSH3hHuHX5qAOqM7JU2w4zqry_rhqiuw@mail.gmail.com>

28 октября 2011 г. 15:05 пользователь Oleg Kostyuk <cub.uanic на gmail.com>написал:

> А поделитесь, пожалуйста, практическим примером.
>
> У меня буквально на днях возник проект в двумя схемами (Pg). Начал
> думать как сделать - две dbic-шных схемы или одну? Мэтт на irc говорит
> делай одну. Ну, в результате сделал примерно так:
>
> lib/....../Schema/DB.pm
> .......
> __PACKAGE__->load_namespaces(
>    result_namespace    => 'Class',
>    resultset_namespace => 'ResultSet',
> );
> .......
>
> Ну и далее всё в файлах lib/....../Schema/DB/Class/Data/*.pm и
> lib/....../Schema/DB/Class/Public/*.pm - для схем data и public
> соответственно. Чтоб не писать в table() имена таблиц с именем схемы
> (а то мало ли - сегодня таблица в одной схеме, завтра в другой) -
> использовал on_connect_do как описано в DBIx::Class::Storage::DBI::Pg.
> К сожалению, проект свернули, практически сразу, потому я не знаю, что
> из этого получилось бы в дальнейшем, и на сколько это вообще было бы
> удобно на практике.
>
> Потому собственно и вопрос - а как было у вас? Поделитесь.
>

У нас MySQL, поэтому разные схемы фактически означают разные БД. И всё это
на работающей системе из полутора десятков приложений, использующих с эти
схемы.

-- 
Andrei Protasovitski
< andrei[dot]protasovitski[at]gmail[dot]com >
Diemen, Netherlands
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/bb2a0a19/attachment.html>

From mi на ya.ru  Fri Oct 28 07:40:37 2011
From: mi на ya.ru (Nikolay Mishin)
Date: Fri, 28 Oct 2011 18:40:37 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?79TLzMDexc7JxSB3YXJuaW5ncyAndW5pbml0aWFs?=
	=?koi8-r?b?aXplZCc=?=
In-Reply-To: <490891319811787@web28.yandex.ru>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<20111028125610.GA90815@tetsuo.karasik.eu.org>
	<CAKb9G9j1LULY+dWGAveJEN5uOw46eg5Pdg2z03xj53p-f-erwQ@mail.gmail.com>
	<20111028131646.GA91478@tetsuo.karasik.eu.org>
	<CAKb9G9im_L6bLS-EF7rDFqpmX-keNxgvsCvUfG7GftESEE8WVw@mail.gmail.com>
	<CAKb9G9gGx4mkemjLyJXLZY8irKnZtC1zLiet8zCyqr2i0PNv7g@mail.gmail.com>
	<531319811506@web53.yandex.ru> <490891319811787@web28.yandex.ru>
Message-ID: <160991319812837@web36.yandex.ru>

у меня тут на днях лог получился >10Gb из-за uninitialized value,
а все из-за того, что не делал проверок на входные параметры функции, правда, я, когда писал этот модуль даже тесты с документацией не делал, но это как раз проинт его переписать

28.10.2011, 18:23, "Nikolay Mishin" <mi на ya.ru>:
> сорри (исправленный вариант)
>
> use 5.01;
> use Carp;
> my %filials;
> $filials{foo} = 300;
> my $ref_hash = \%filials;
> my @test     = qw/444 33a 2 d 300 ffd 22/;
>
> for $test_val (@test) {
>     $filials{foo} = $test_val;
>     test_var( \%filials );
>     say $test_val;
> }
>
> sub test_var {
>     my $r = shift;
>     croak("Value ***$r->{foo}*** is not defined or not number")
>       if !defined $r->{foo} || $r->{foo} !~ /^\d+$/;
>
>     if ( $r->{foo} > 100 ) {
>         say '$r->{foo} > 100';
>     }
>
> }
>
> 28.10.2011, 18:18, "Nikolay Mishin" <mi на ya.ru>:
>
>>  А почему не так
>>
>>  use 5.01;
>>  use Carp;
>>  my %filials;
>>  $filials{foo} = 300;
>>
>>  #$filials{boo} = 200;
>>  my $ref_hash = \%filials;
>>  my @test     = qw/a 2 d 300 ffd 22/;
>>
>>  #test_var($ref_hash);
>>
>>  for $test_val (@test) {
>>      $filials{foo} = $test_val;
>>      test_var( \%filials );
>>      say $test_val;
>>  }
>>
>>  sub test_var {
>>      my $r = shift;
>>      croak("Value ***$r->{foo}*** is not defined or not number")
>>        if !defined $r->{foo} || $r->{foo} != ~/^\d+$/;
>>
>>      if ( $r->{foo} > 100 ) {
>>          say '$r->{foo} > 100';
>>      }
>>
>>  }
>>
>>  и тогда , если будет ошибка. ты не будешь ломать головку - и где из моих 1000 строк кода она может быть?
>>
>>  28.10.2011, 17:26, "Alexandr Gomoliako" <zzz на zzz.org.ua>:
>>>   On 10/28/11, Alexandr Gomoliako <zzz на zzz.org.ua> wrote:
>>>>    вместо
>>>>        if ($r->{foo} =~ /^\d+$/ && $r->{foo} > 100)
>>>   Я тут наверное даже мало написал, уже забыл:
>>>        if (defined $r->{foo} && $r->{foo} =~ /^\d+$/ && $r->{foo} > 100)
>>>
>>>   --
>>>   Moscow.pm mailing list
>>>   moscow-pm на pm.org | http://moscow.pm.org
>>  --
>>  Nikolay Mishin
>>
>>  --
>>  Moscow.pm mailing list
>>  moscow-pm на pm.org | http://moscow.pm.org
>
> --
> Nikolay Mishin
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

--
Nikolay Mishin

From zzz на zzz.org.ua  Fri Oct 28 07:41:44 2011
From: zzz на zzz.org.ua (Alexandr Gomoliako)
Date: Fri, 28 Oct 2011 17:41:44 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?79TLzMDexc7JxSB3YXJuaW5ncyAndW5pbml0aWFs?=
	=?koi8-r?b?aXplZCc=?=
In-Reply-To: <CAA4UdcTZLqb7HBZiyhkicJXCnNVedLXiJp71roq68Gb=k2Rcxg@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<CALE3dTUiM6XuPGVFMuPVLVZb9hO2rZ4ff8JgMsBF4dT=BAyWCg@mail.gmail.com>
	<CANh0x-xLAFRa-LoPsL1-Vd7hVvi-mU05B64uqkKBmyuyDzSHQA@mail.gmail.com>
	<20111028114917.GY24610@rabbit.us>
	<CANh0x-yHG9Y+4xygW3SVLm9-sfZNCdabJAsLHBON0Vt3V8su5A@mail.gmail.com>
	<CAA4UdcTZLqb7HBZiyhkicJXCnNVedLXiJp71roq68Gb=k2Rcxg@mail.gmail.com>
Message-ID: <CAKb9G9g7B0T9g40r0AZe2c4VyuXzgN82TG+Ak2d80thYNsgVxA@mail.gmail.com>

On 10/28/11, Nikita Zubkov <nikzubkov на gmail.com> wrote:
> Главная проблема у warnings 'uninitialized' и других схожих - огромное
> количество "ложных" срабатываний.

Каких еще ложных срабатываний? Есть пример?

From cub.uanic на gmail.com  Fri Oct 28 07:51:11 2011
From: cub.uanic на gmail.com (Oleg Kostyuk)
Date: Fri, 28 Oct 2011 17:51:11 +0300
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <CANVWn7FVbpz-a6gpy+jSH3hHuHX5qAOqM7JU2w4zqry_rhqiuw@mail.gmail.com>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
	<DA5EB15E-49FF-40B8-ADCF-DB0D1CCEF1D8@aaanet.ru>
	<CANVWn7FPn__UuDTUaqioRsb77RjcbTdpkHA2+kTPAojHwBjykQ@mail.gmail.com>
	<974D6334-ECA7-4008-9001-60BF7261C709@aaanet.ru>
	<CANVWn7Fxrtnm_n8kv5T+bFBWq5MwF=GFjnBmWNn=VWAKNHyggw@mail.gmail.com>
	<CAAPa60j4thXS_5Ez=wykOdi3+S2=0+KYS+oy65Zd2HL60jjmeg@mail.gmail.com>
	<CANVWn7FVbpz-a6gpy+jSH3hHuHX5qAOqM7JU2w4zqry_rhqiuw@mail.gmail.com>
Message-ID: <CAAPa60j7Vb9UEZ8wBxRqLxwuhhbbWQTZBCs59G8Q6fUfYL23jQ@mail.gmail.com>

Так я про это:

> Это когда раньше все данные лежали в одной схеме,
> а потом оказалось, что их чересчур много и имеет смыл
> некоторые положить в другую схему. В этом случае то,
> что раньше делалось со всякими JOIN'ами, в новой
> реальности работать не будет, потому что схемы
> лежат в разных коробках. И вот здесь наличие
> абстракции в виде ORM сильно помогает.

Как оно вам помогает? Как вы работаете с несколькими схемами в бд? В
смысле DBIC - у вас одна или несколько схем? Покажте же код, хотябы в
общих чертах :)

Я показал (в общих чертах) как это начал делать сам. Но дело до конца
не дошло, потому интересен чужой практический опыт. И то, что у вас
MySQL а не Pg - для меня только увеличивает интересность. Ведь в Pg в
перелах одной dbic-схемы можно за-джойнить данные из таблиц, лежащих в
разных дб-схемах, т.к. база-то одна. А у вас в MySQL базы-то разные, и
это уже не катит. Потому и хочется конкретики.


28 октября 2011 г. 17:28 пользователь Andrei
<andrei.protasovitski на gmail.com> написал:
> 28 октября 2011 г. 15:05 пользователь Oleg Kostyuk <cub.uanic на gmail.com>
> написал:
>>
>> А поделитесь, пожалуйста, практическим примером.
>>
>> У меня буквально на днях возник проект в двумя схемами (Pg). Начал
>> думать как сделать - две dbic-шных схемы или одну? Мэтт на irc говорит
>> делай одну. Ну, в результате сделал примерно так:
>>
>> lib/....../Schema/DB.pm
>> .......
>> __PACKAGE__->load_namespaces(
>>    result_namespace    => 'Class',
>>    resultset_namespace => 'ResultSet',
>> );
>> .......
>>
>> Ну и далее всё в файлах lib/....../Schema/DB/Class/Data/*.pm и
>> lib/....../Schema/DB/Class/Public/*.pm - для схем data и public
>> соответственно. Чтоб не писать в table() имена таблиц с именем схемы
>> (а то мало ли - сегодня таблица в одной схеме, завтра в другой) -
>> использовал on_connect_do как описано в DBIx::Class::Storage::DBI::Pg.
>> К сожалению, проект свернули, практически сразу, потому я не знаю, что
>> из этого получилось бы в дальнейшем, и на сколько это вообще было бы
>> удобно на практике.
>>
>> Потому собственно и вопрос - а как было у вас? Поделитесь.
>
> У нас MySQL, поэтому разные схемы фактически означают разные БД. И всё это
> на работающей системе из полутора десятков приложений, использующих с эти
> схемы.
>
> --
> Andrei Protasovitski
> < andrei[dot]protasovitski[at]gmail[dot]com >
> Diemen, Netherlands
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>



-- 
Sincerely yours,
Oleg Kostyuk (CUB-UANIC)

From andrei.protasovitski на gmail.com  Fri Oct 28 08:00:04 2011
From: andrei.protasovitski на gmail.com (Andrei)
Date: Fri, 28 Oct 2011 17:00:04 +0200
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <CALzA1MwbaxNhzwALE-SbepLeUD0Qj8e78bOVgF7w4-LgnixQ3w@mail.gmail.com>
References: <20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
	<CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
	<20111028112123.GR20514@apache.rbscorp.ru>
	<20111028112649.GS24610@rabbit.us>
	<20111028113008.GV20514@apache.rbscorp.ru>
	<20111028114010.GV24610@rabbit.us>
	<CALzA1Mxwv2brHxvXTdjgk_wP4nzq-_VgP=C3w_rukQJ9rzifCQ@mail.gmail.com>
	<CANVWn7FNdDhySqh8-MmGaUpQwgVK9esZgvnNGiVcGs6+d4iYnQ@mail.gmail.com>
	<CALzA1MwbaxNhzwALE-SbepLeUD0Qj8e78bOVgF7w4-LgnixQ3w@mail.gmail.com>
Message-ID: <CANVWn7EPB-0xWptzgTratPs2bzjxi3-jENvMdPpC5zw9_vpq0w@mail.gmail.com>

28 октября 2011 г. 15:37 пользователь Михаил Шогин <mshogin на gmail.com>написал:

> Объясните, пожалуйста, разработчикам, что null означает "отсутсвие данных",
>> только "отсутсвие данных" и ничего, кроме "отсутствия данных". Разработчики,
>> работающие с базами данных, должны понимать, что "отсутсвие данных" не может
>> быть использовано как "данные".
>>
>> В этом конкретном случае "запись недоступна" есть некоторые вполне
>> определённые данные, и для этого статуса должно быть определено полне
>> конкретное значение.
>>
>> NULL - тоже значение.
>
> Объяснение простое,
> Поле выставляется в значение NULL для не попадания в индекс.
>

Какой в этом смысл?

Согласен что было бы лучше сделать так
> status - доступность сущности ( 1 - доступна , 0 - не доступна )
>
> однако в таком случае пришлось бы строить индекс
>
> create index ENTITIES$N$STATUSACTIVE on books (n, case when status = 1 then
> 1 else null end )
>
> но в таком случае, для того что бы пойти по индексу, придется использовать
> запрос вида
>
> select en.n
>   from entities en
> where case
>                when en.status = 1
>                then 1
>                else null
>           end  = 1
>

A почему нельзя просто WHERE en.status = 1 ?

-- 
Andrei Protasovitski
< andrei[dot]protasovitski[at]gmail[dot]com >
Diemen, Netherlands
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/aec644b5/attachment.html>

From cub.uanic на gmail.com  Fri Oct 28 08:11:13 2011
From: cub.uanic на gmail.com (Oleg Kostyuk)
Date: Fri, 28 Oct 2011 18:11:13 +0300
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <CANVWn7EPB-0xWptzgTratPs2bzjxi3-jENvMdPpC5zw9_vpq0w@mail.gmail.com>
References: <20111027201358.GB13125@rabbit.us>
	<20111027203257.GD19081@apache.rbscorp.ru>
	<CANVWn7G5RZbX9Cuf9J9q3g3CfjchVd6pjjrMwzLgo9yAL6fUBQ@mail.gmail.com>
	<20111028062003.GC20514@apache.rbscorp.ru>
	<05925c5fb76fa04ed78132478327b322@aumi.ru>
	<20111028070733.GG20514@apache.rbscorp.ru>
	<CANVWn7Ehh8tMnAf2966_J1Gr8kZesiVveeSo3bSgHnQ9YhZ=4Q@mail.gmail.com>
	<20111028112123.GR20514@apache.rbscorp.ru>
	<20111028112649.GS24610@rabbit.us>
	<20111028113008.GV20514@apache.rbscorp.ru>
	<20111028114010.GV24610@rabbit.us>
	<CALzA1Mxwv2brHxvXTdjgk_wP4nzq-_VgP=C3w_rukQJ9rzifCQ@mail.gmail.com>
	<CANVWn7FNdDhySqh8-MmGaUpQwgVK9esZgvnNGiVcGs6+d4iYnQ@mail.gmail.com>
	<CALzA1MwbaxNhzwALE-SbepLeUD0Qj8e78bOVgF7w4-LgnixQ3w@mail.gmail.com>
	<CANVWn7EPB-0xWptzgTratPs2bzjxi3-jENvMdPpC5zw9_vpq0w@mail.gmail.com>
Message-ID: <CAAPa60iP6dRud0bM3SZvNhKHAQFk2JjFmVpv1DUXrfMvvqtm6Q@mail.gmail.com>

28 октября 2011 г. 18:00 пользователь Andrei
<andrei.protasovitski на gmail.com> написал:
> 28 октября 2011 г. 15:37 пользователь Михаил Шогин <mshogin на gmail.com>
> написал:
>>>
>>> Объясните, пожалуйста, разработчикам, что null означает "отсутсвие
>>> данных", только "отсутсвие данных" и ничего, кроме "отсутствия данных".
>>> Разработчики, работающие с базами данных, должны понимать, что "отсутсвие
>>> данных" не может быть использовано как "данные".
>>>
>>> В этом конкретном случае "запись недоступна" есть некоторые вполне
>>> определённые данные, и для этого статуса должно быть определено полне
>>> конкретное значение.
>>>
>> NULL - тоже значение.
>> Объяснение простое,
>> Поле выставляется в значение NULL для не попадания в индекс.
>
> Какой в этом смысл?
Вероятно, для уменьшения размера индекса. И таким образом - повышения
его селективности.

Лично мне, Андрей, ваша позиция понятна и я её всячески приветствую. Я
не против вас. Но реалии таковы, что в некоторых случаях бывает
выгодно и уместно идти на всякого рода трюки. Если ситуация оценена
всесторонне и решение принималось взвешенно, а не просто потому что "в
прошлом проекте делал так и там всё было классно" - то наверное, такие
трюки уместны. Конечно, при наличии не только обоснования, но и
внутрипроектной документации. Единственное "но" - в данном конкретнос
случае я бы предпочёл пару (NULL || 1) вместо (NULL || 0), чисто из
"перловских" соображений.

Андрей, я буду рад, если вы предложите лучшее решение, достигающее
_всех_ техже целей.


>> Согласен что было бы лучше сделать так
>> status - доступность сущности ( 1 - доступна , 0 - не доступна )
>> однако в таком случае пришлось бы строить индекс
>> create index ENTITIES$N$STATUSACTIVE on books (n, case when status = 1
>> then 1 else null end )
>> но в таком случае, для того что бы пойти по индексу, придется использовать
>> запрос вида
>> select en.n
>>   from entities en
>> where case
>>                when en.status = 1
>>                then 1
>>                else null
>>           end  = 1
>
> A почему нельзя просто WHERE en.status = 1 ?
>
> --
> Andrei Protasovitski
> < andrei[dot]protasovitski[at]gmail[dot]com >
> Diemen, Netherlands
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>



-- 
Sincerely yours,
Oleg Kostyuk (CUB-UANIC)

From evdokimov.denis на gmail.com  Fri Oct 28 08:13:50 2011
From: evdokimov.denis на gmail.com (Denis Evdokimov)
Date: Fri, 28 Oct 2011 19:13:50 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?79TLzMDexc7JxSB3YXJuaW5ncyAndW5pbml0aWFs?=
	=?koi8-r?b?aXplZCc=?=
In-Reply-To: <CAKb9G9hGteuxWYxx-e=cO9NdHyoRbL4j2z1RqjnuL8pKYSNdnw@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<20111028125610.GA90815@tetsuo.karasik.eu.org>
	<CAKb9G9j1LULY+dWGAveJEN5uOw46eg5Pdg2z03xj53p-f-erwQ@mail.gmail.com>
	<20111028131646.GA91478@tetsuo.karasik.eu.org>
	<CAKb9G9im_L6bLS-EF7rDFqpmX-keNxgvsCvUfG7GftESEE8WVw@mail.gmail.com>
	<CAKb9G9gGx4mkemjLyJXLZY8irKnZtC1zLiet8zCyqr2i0PNv7g@mail.gmail.com>
	<CAFdXSm-bVJUzYSBaMShvLrXgm3oFmXh9mPC1mHBSZM8kjMgmJg@mail.gmail.com>
	<CAKb9G9gUbC-KFJFpc1UHAM6tKXmedSZv9sFmphp_-Ai2VnhFpQ@mail.gmail.com>
	<CAFdXSm-fKLySgpH8DUHB9fW5Ous4N5KrT4x+-9p7-aBf5K6_4Q@mail.gmail.com>
	<CAKb9G9jqd2affshOA3HDkfSzCsFS4aY+K5i2c1ZKevhN03NTbA@mail.gmail.com>
	<CAFdXSm9g-T6hzW1hSJx20hosKOjfd0ut3-8Q60tH-Fk83nXN+w@mail.gmail.com>
	<CAKb9G9hGteuxWYxx-e=cO9NdHyoRbL4j2z1RqjnuL8pKYSNdnw@mail.gmail.com>
Message-ID: <CAFdXSm_XuWvnb1LzE1RrtRDJpt1humOuxW74qptrOOBVU0ePnQ@mail.gmail.com>

Александр, если ситуация, когда вместо числа пришел текст является
нормальной, тогда да, варнинги не нужны.

28 октября 2011 г. 17:54 пользователь Alexandr Gomoliako
<zzz на zzz.org.ua>написал:

> On 10/28/11, Denis Evdokimov <evdokimov.denis на gmail.com> wrote:
> > Правильно ли я Вас понимаю, что
> >
> > $r->{cnt} = "bla-bla-bla";
> > ...
> > if ( $r->{cnt} > 100 )
> >
> > Нормальная ситуация и ругаться не стоит?
>
> Да.
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/a250b765/attachment.html>

From nikzubkov на gmail.com  Fri Oct 28 08:15:03 2011
From: nikzubkov на gmail.com (Nikita Zubkov)
Date: Fri, 28 Oct 2011 19:15:03 +0400
Subject: [Moscow.pm] =?utf-8?b?0J7RgtC60LvRjtGH0LXQvdC40LUgd2FybmluZ3Mg?=
	=?utf-8?q?=27uninitialized=27?=
In-Reply-To: <CAKb9G9g7B0T9g40r0AZe2c4VyuXzgN82TG+Ak2d80thYNsgVxA@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<CALE3dTUiM6XuPGVFMuPVLVZb9hO2rZ4ff8JgMsBF4dT=BAyWCg@mail.gmail.com>
	<CANh0x-xLAFRa-LoPsL1-Vd7hVvi-mU05B64uqkKBmyuyDzSHQA@mail.gmail.com>
	<20111028114917.GY24610@rabbit.us>
	<CANh0x-yHG9Y+4xygW3SVLm9-sfZNCdabJAsLHBON0Vt3V8su5A@mail.gmail.com>
	<CAA4UdcTZLqb7HBZiyhkicJXCnNVedLXiJp71roq68Gb=k2Rcxg@mail.gmail.com>
	<CAKb9G9g7B0T9g40r0AZe2c4VyuXzgN82TG+Ak2d80thYNsgVxA@mail.gmail.com>
Message-ID: <CAA4UdcSzQNP3JaXbBbA4q-+VptxVM2qQQQOAAwJwbFL--0_mgQ@mail.gmail.com>

Я не зря написал слово "ложных" в кавычках. С формальной точки зрения
эти срабатывания не ложные, но с т.з. логики приложение они ложные.

if( $a =~ /^[a-z]+$/ )

Если $a удовляетворяет регулярному выражению, то $a не может быть
undef. Зачем писать лишнюю проверку? Ладно, в данном случае я напишу
так:

if( $a && $a =~ /^[a-z]+$/ )

Ситуация хуже:

if( $a =~ /^[0-9]+$/ )

В данном случае проверять $a на истину уже не достаточно, так как '0'
- валидная строка. Нужно писать defined $a. В результате код пестрит
кучей ненужных частично дублирующих друг друга проверок, что ухудшает
читабельность кода. Пропустили проверку, получили в продакшене лог,
содержащий 90% варнингов и 10% полезной отладочной информации.

Одни расстройства.

28 октября 2011 г. 18:41 пользователь Alexandr Gomoliako
<zzz на zzz.org.ua> написал:
> On 10/28/11, Nikita Zubkov <nikzubkov на gmail.com> wrote:
>> Главная проблема у warnings 'uninitialized' и других схожих - огромное
>> количество "ложных" срабатываний.
>
> Каких еще ложных срабатываний? Есть пример?
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
С уважением,
Никита Зубков

From ruz на bestpractical.com  Fri Oct 28 12:08:57 2011
From: ruz на bestpractical.com (Ruslan Zakirov)
Date: Fri, 28 Oct 2011 23:08:57 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <20111028111031.GO20514@apache.rbscorp.ru>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<CAFtO3fn3n0VeaTh8NtOyYpyiJQeeiVxO9OKBNbV=bhCcSXe7Kw@mail.gmail.com>
	<20111028111031.GO20514@apache.rbscorp.ru>
Message-ID: <CAMOxC8uz6muH_UJKZpDUi7QZOmPL8zmvT700XMuizz212VZGqQ@mail.gmail.com>

2011/10/28 Ivan Petrov <i.petro.77.00 на gmail.com>:
>> А что рельсы отменили?
>
> у нас есть Mojo, но это не то. и в рельсах и в Mojo темплейты.
>
> то есть ручное рисование html.
> а раз местная аудитория утверждает что темплейты в SQL нафиг не нужны,
> поскольку удалось все так круто автоматизировать, шо "оно само все
> делает", я и предлагаю им пойти дальше. и отказаться от темплейтов в
> html. зачем?

Сейчас есть CSS фреймворки, которые частично фиксируют шаблон для
различных элементов, то есть нет необходимости в верстальщике как в
специалисте HTML разметки. Когда все укладывается в предоставленный
набор элементов, то можно из хеша элементарно собрать форму :) Это не
панацея.

С каждым годом поддержка CSS и JS улучшается. Например: раньше мы
рекомендовали клиентам копировать файлы шаблонов и переносить блоки
html, а теперь рекомендуем однострочники на JS, что-то типа
jQuery('selector').appendTo('selector').

С каждым годом работа frontend разработчика становится все более
независимой от HTML кода.

Если взять bootstrap в качестве CSS фреймворка, то элементарно
написать конвертер из структур любого языка в HTML. Поле возможностей
ограничено значительно и задача упрощается.

Еще пример metacpan.org, где HTML отделен от серверной части.

> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
Best regards, Ruslan.

From mons на rambler-co.ru  Fri Oct 28 13:00:15 2011
From: mons на rambler-co.ru (Mons Anderson)
Date: Sat, 29 Oct 2011 00:00:15 +0400
Subject: [Moscow.pm] =?utf-8?b?0J7RgtC60LvRjtGH0LXQvdC40LUgd2FybmluZ3Mg?=
 =?utf-8?q?=27uninitialized=27?=
In-Reply-To: <CANh0x-yHG9Y+4xygW3SVLm9-sfZNCdabJAsLHBON0Vt3V8su5A@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<CALE3dTUiM6XuPGVFMuPVLVZb9hO2rZ4ff8JgMsBF4dT=BAyWCg@mail.gmail.com>
	<CANh0x-xLAFRa-LoPsL1-Vd7hVvi-mU05B64uqkKBmyuyDzSHQA@mail.gmail.com>
	<20111028114917.GY24610@rabbit.us>
	<CANh0x-yHG9Y+4xygW3SVLm9-sfZNCdabJAsLHBON0Vt3V8su5A@mail.gmail.com>
Message-ID: <58CAA63A-2D18-4F3C-B382-F89BF74EF33E@rambler-co.ru>

Попробую ответить зачем я так делаю.

У автора common::sence вполне понятно написано почему он так сделал и я его мнение разделяю.

Есть варнинги, которым стоит быть фатальными ошибками. А есть те, которые только мешают.
Особенно меня бесит, когда нормально написаный и вполне валидный код, который хорошо покрыт тестами и нормально работает вдруг начинает варниться, когда какой-то "нехороший" человек сделал perl -w.

Дело не в оверхеде (которого действительно нет), а в понимании того, каким должен быть язык.
Мне не нравится тот подход, который пытается сделать из языка Perl язык подобный Java или C++, т.е. более строгим, ограниченным.

Соответственно я позаимствовал у Марка идею, хотя сделал ее по своему. т.е. у меня (uni::perl) отключено меньшее кол-во варнингов, в частности категория utf8 оставлена и сделана фатальной.

А вообще общий ответ: мне так удобнее.
Я четко знаю что и как работает. Для меня в перле нет магии: есть четкое понимание правил, особенностей и возможностей. Я знаю, что я могу трактовать undef как строку или строку как число. Я не забываю про то, что это может быть, я просто этим пользуюсь, когда мне не важны проверки или пишу defined, когда мне действительно важно это проверять.

Кому-то, например, Moose удобен, а я не выношу его overhead и убогий избыточный синтаксис. На мой взгляд это не Perl way.
Но при этом я не пытаюсь всех убедить в том, какой Moose неправильный.

TIMTOWTDI. Я пользуюсь тем, что удобно _мне_. Я рад, если кому-то еще это удобно. Я не буду вас убеждать, что вы пользуетесь чем-то неправильным только из-за того, что это неудобно, например, мне.

On 28.10.2011, at 17:52, Ilya Chesnokov wrote:

> 28 октября 2011 г. 15:49 пользователь Peter Rabbitson
> <rabbit+moscowpm на rabbit.us> написал:
>> On Fri, Oct 28, 2011 at 03:36:34PM +0400, Ilya Chesnokov wrote:
>>> На самом деле вопрос в том, что я на работе хочу отключить эти самые
>>> warnings 'uninitialized', но в реале получается, что они действительно
>>> бывают полезны для отлова некоторых косяков.
>> 
>> А можно поинтерисоватся зачем? Оверхед у strict/warnings практически
>> отсуствует (все реализованно в Sv флагах, которые переключаются *вне
>> зависимости* от того будет perl шипеть или нет).
> 
> В принципе, манит грешный путь, который пропагандирует Alexandr Gomoliako.
> "Красивый" код, меньше "букаф", вроде бы всё более удобно и гламурно.
> 
> Поэтому и хотелось бы узнать мнение тех людей, которые отключают
> warnings 'uninitialized' -- например, Шарифулина и Монса -- не боитесь
> ли вы пропустить какую-нибудь ошибку, отключив эти варнинги? И что в
> вас в таком случае вселяет уверенность в том, что вы не пропустите
> какой-нибудь важный баг?
> 
> -- 
> Best regards,
> Ilya Chesnokov
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org


From dmitry на karasik.eu.org  Fri Oct 28 13:41:00 2011
From: dmitry на karasik.eu.org (Dmitry Karasik)
Date: Fri, 28 Oct 2011 22:41:00 +0200
Subject: [Moscow.pm]
	=?koi8-r?b?79TLzMDexc7JxSB3YXJuaW5ncyAndW5pbml0aWFs?=
	=?koi8-r?b?aXplZCc=?=
In-Reply-To: <58CAA63A-2D18-4F3C-B382-F89BF74EF33E@rambler-co.ru>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<CALE3dTUiM6XuPGVFMuPVLVZb9hO2rZ4ff8JgMsBF4dT=BAyWCg@mail.gmail.com>
	<CANh0x-xLAFRa-LoPsL1-Vd7hVvi-mU05B64uqkKBmyuyDzSHQA@mail.gmail.com>
	<20111028114917.GY24610@rabbit.us>
	<CANh0x-yHG9Y+4xygW3SVLm9-sfZNCdabJAsLHBON0Vt3V8su5A@mail.gmail.com>
	<58CAA63A-2D18-4F3C-B382-F89BF74EF33E@rambler-co.ru>
Message-ID: <20111028204100.GA31927@tetsuo.karasik.eu.org>

> А вообще общий ответ: мне так удобнее.

+1
четко и по делу )


-- 
Sincerely,
	Dmitry Karasik


From chesnokov.ilya на gmail.com  Fri Oct 28 13:43:32 2011
From: chesnokov.ilya на gmail.com (Ilya Chesnokov)
Date: Sat, 29 Oct 2011 00:43:32 +0400
Subject: [Moscow.pm] =?utf-8?b?0J7RgtC60LvRjtGH0LXQvdC40LUgd2FybmluZ3Mg?=
	=?utf-8?q?=27uninitialized=27?=
In-Reply-To: <58CAA63A-2D18-4F3C-B382-F89BF74EF33E@rambler-co.ru>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<CALE3dTUiM6XuPGVFMuPVLVZb9hO2rZ4ff8JgMsBF4dT=BAyWCg@mail.gmail.com>
	<CANh0x-xLAFRa-LoPsL1-Vd7hVvi-mU05B64uqkKBmyuyDzSHQA@mail.gmail.com>
	<20111028114917.GY24610@rabbit.us>
	<CANh0x-yHG9Y+4xygW3SVLm9-sfZNCdabJAsLHBON0Vt3V8su5A@mail.gmail.com>
	<58CAA63A-2D18-4F3C-B382-F89BF74EF33E@rambler-co.ru>
Message-ID: <CANh0x-wPkUofkHAjxQCWcaHHyp5DaV9_RsdZ1fnpaUpjC-xfYw@mail.gmail.com>

29 октября 2011 г. 0:00 пользователь Mons Anderson <mons на rambler-co.ru> написал:
> Попробую ответить зачем я так делаю.
[skip]
> TIMTOWTDI. Я пользуюсь тем, что удобно _мне_. Я рад, если кому-то еще это удобно. Я не буду вас убеждать, что вы пользуетесь чем-то неправильным только из-за того, что это неудобно, например, мне.

Спасибо за ответ.

Но с практической точки зрения я понял только то, что отключение
предупреждений о неинициализированном значении -- это такая ловушка, о
которой если ты помнишь, то будешь стараться покрывать свой код
тестами и делать его максимально надежным и безопасным -- чтобы не
сделать rmtree "$HOME/undef" -- хотя тут и warning не поможет. Если же
ты при отключенных варнингах забудешь о дополнительных проверках --
жди неприятностей.

И ещё я понял, что Монс -- очень счастливый человек, раз может
позволить себе программировать, так как удобно _ему_ :)) А не пытаться
убедить свой рабочий коллектив, что и _им_ тоже будет так удобнее ;))

-- 
Best regards,
Ilya Chesnokov

From andrei.protasovitski на gmail.com  Fri Oct 28 14:15:27 2011
From: andrei.protasovitski на gmail.com (Andrei)
Date: Fri, 28 Oct 2011 23:15:27 +0200
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <CAAPa60j7Vb9UEZ8wBxRqLxwuhhbbWQTZBCs59G8Q6fUfYL23jQ@mail.gmail.com>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
	<DA5EB15E-49FF-40B8-ADCF-DB0D1CCEF1D8@aaanet.ru>
	<CANVWn7FPn__UuDTUaqioRsb77RjcbTdpkHA2+kTPAojHwBjykQ@mail.gmail.com>
	<974D6334-ECA7-4008-9001-60BF7261C709@aaanet.ru>
	<CANVWn7Fxrtnm_n8kv5T+bFBWq5MwF=GFjnBmWNn=VWAKNHyggw@mail.gmail.com>
	<CAAPa60j4thXS_5Ez=wykOdi3+S2=0+KYS+oy65Zd2HL60jjmeg@mail.gmail.com>
	<CANVWn7FVbpz-a6gpy+jSH3hHuHX5qAOqM7JU2w4zqry_rhqiuw@mail.gmail.com>
	<CAAPa60j7Vb9UEZ8wBxRqLxwuhhbbWQTZBCs59G8Q6fUfYL23jQ@mail.gmail.com>
Message-ID: <CANVWn7FVc4tKu+LRjEF9+kPFVJ+wzp52jZdMQ2K8ZDZtuJx1iw@mail.gmail.com>

28 октября 2011 г. 16:51 пользователь Oleg Kostyuk <cub.uanic на gmail.com>написал:

> Так я про это:
>
> > Это когда раньше все данные лежали в одной схеме,
> > а потом оказалось, что их чересчур много и имеет смыл
> > некоторые положить в другую схему. В этом случае то,
> > что раньше делалось со всякими JOIN'ами, в новой
> > реальности работать не будет, потому что схемы
> > лежат в разных коробках. И вот здесь наличие
> > абстракции в виде ORM сильно помогает.
>
> Как оно вам помогает? Как вы работаете с несколькими схемами в бд? В
> смысле DBIC - у вас одна или несколько схем? Покажте же код, хотябы в
> общих чертах :)
>
> Я показал (в общих чертах) как это начал делать сам. Но дело до конца
> не дошло, потому интересен чужой практический опыт. И то, что у вас
> MySQL а не Pg - для меня только увеличивает интересность. Ведь в Pg в
> перелах одной dbic-схемы можно за-джойнить данные из таблиц, лежащих в
> разных дб-схемах, т.к. база-то одна. А у вас в MySQL базы-то разные, и
> это уже не катит. Потому и хочется конкретики.
>

Так у нас ещё и Class::DBI. :)

Ничего там особенного нет. Каждая БД имеет свой базовый класс, который
наследуется от того же Class::DBI, только использует свои DSN. От классов БД
наследуются врапперы таблиц. Всё предельно просто.

-- 
Andrei Protasovitski
< andrei[dot]protasovitski[at]gmail[dot]com >
Diemen, Netherlands
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111028/18ab5e3e/attachment-0001.html>

From sharifulin на gmail.com  Fri Oct 28 14:27:07 2011
From: sharifulin на gmail.com (=?KOI8-R?B?4c7B1M/Mycog+8HSycbVzMnO?=)
Date: Sat, 29 Oct 2011 01:27:07 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?79TLzMDexc7JxSB3YXJuaW5ncyAndW5pbml0aWFs?=
	=?koi8-r?b?aXplZCc=?=
In-Reply-To: <CANh0x-zETOK1OWo5aVR8XE=840P_ZSiBKDO1JnY8rsJdBdd0eg@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<20111028125610.GA90815@tetsuo.karasik.eu.org>
	<CAKb9G9j1LULY+dWGAveJEN5uOw46eg5Pdg2z03xj53p-f-erwQ@mail.gmail.com>
	<20111028131646.GA91478@tetsuo.karasik.eu.org>
	<CAKb9G9im_L6bLS-EF7rDFqpmX-keNxgvsCvUfG7GftESEE8WVw@mail.gmail.com>
	<CANh0x-zETOK1OWo5aVR8XE=840P_ZSiBKDO1JnY8rsJdBdd0eg@mail.gmail.com>
Message-ID: <CAJG5KK73Se7eDST1zwzVhiuVeMQmomvRJK55DCJ5y_vV3V=VoQ@mail.gmail.com>

2011/10/28 Ilya Chesnokov <chesnokov.ilya на gmail.com>

> На следующий же день пришло автоматическое письмо со списком
> варнингов, случившихся за прошедший день, в числе которых был и этот
> варнинг с "use of uninitialized value" в ключе хеша.
>

Вот это крутая тема, если есть время это разбирать и исправлять каждый день,
то вы лучшая команда по поддержке кода (по крайней мере, стремитесь к
этому).

-- 
С уважением,
 Анатолий Шарифулин.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111029/9cc166c4/attachment.html>

From sharifulin на gmail.com  Fri Oct 28 14:34:43 2011
From: sharifulin на gmail.com (=?KOI8-R?B?4c7B1M/Mycog+8HSycbVzMnO?=)
Date: Sat, 29 Oct 2011 01:34:43 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?79TLzMDexc7JxSB3YXJuaW5ncyAndW5pbml0aWFs?=
	=?koi8-r?b?aXplZCc=?=
In-Reply-To: <CANh0x-yHG9Y+4xygW3SVLm9-sfZNCdabJAsLHBON0Vt3V8su5A@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<CALE3dTUiM6XuPGVFMuPVLVZb9hO2rZ4ff8JgMsBF4dT=BAyWCg@mail.gmail.com>
	<CANh0x-xLAFRa-LoPsL1-Vd7hVvi-mU05B64uqkKBmyuyDzSHQA@mail.gmail.com>
	<20111028114917.GY24610@rabbit.us>
	<CANh0x-yHG9Y+4xygW3SVLm9-sfZNCdabJAsLHBON0Vt3V8su5A@mail.gmail.com>
Message-ID: <CAJG5KK4hL0HXnLPLfoFpDPJ=NxwdSMw0MSqkJr0S+KCyphECkg@mail.gmail.com>

2011/10/28 Ilya Chesnokov <chesnokov.ilya на gmail.com>

> Поэтому и хотелось бы узнать мнение тех людей, которые отключают
> warnings 'uninitialized' -- например, Шарифулина и Монса -- не боитесь
> ли вы пропустить какую-нибудь ошибку, отключив эти варнинги? И что в
> вас в таком случае вселяет уверенность в том, что вы не пропустите
> какой-нибудь важный баг?
>

Если это приводит к ошибке, то либо вы об этом узнаете как об ошибке, либо
не узнаете никогда.
Остаётся один только вопрос: цена ошибки, но это не в рамках обсуждения
'uninitialized'.

Незачем тратить своё время на попытку написать идеальный код или покурыть
тестами "каждый чих", это невозможно.

А писать красивый компактный код, обрезав "лишнее" -- это и приятно, и
полезно.

-- 
С уважением,
 Анатолий Шарифулин.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111029/0127870d/attachment.html>

From rabbit+moscowpm на rabbit.us  Fri Oct 28 15:18:28 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 18:18:28 -0400
Subject: [Moscow.pm] =?utf-8?b?0J7RgtC60LvRjtGH0LXQvdC40LUgd2FybmluZ3Mg?=
	=?utf-8?q?=27uninitialized=27?=
In-Reply-To: <CANh0x-wPkUofkHAjxQCWcaHHyp5DaV9_RsdZ1fnpaUpjC-xfYw@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<CALE3dTUiM6XuPGVFMuPVLVZb9hO2rZ4ff8JgMsBF4dT=BAyWCg@mail.gmail.com>
	<CANh0x-xLAFRa-LoPsL1-Vd7hVvi-mU05B64uqkKBmyuyDzSHQA@mail.gmail.com>
	<20111028114917.GY24610@rabbit.us>
	<CANh0x-yHG9Y+4xygW3SVLm9-sfZNCdabJAsLHBON0Vt3V8su5A@mail.gmail.com>
	<58CAA63A-2D18-4F3C-B382-F89BF74EF33E@rambler-co.ru>
	<CANh0x-wPkUofkHAjxQCWcaHHyp5DaV9_RsdZ1fnpaUpjC-xfYw@mail.gmail.com>
Message-ID: <20111028221828.GB20103@rabbit.us>

On Sat, Oct 29, 2011 at 12:43:32AM +0400, Ilya Chesnokov wrote:
> тестами и делать его максимально надежным и безопасным -- чтобы не
> сделать rmtree "$HOME/undef" -- хотя тут и warning не поможет. Если же

use warnings FATAL => 'all' поможет :)

From mons на rambler-co.ru  Fri Oct 28 16:35:38 2011
From: mons на rambler-co.ru (Mons Anderson)
Date: Sat, 29 Oct 2011 03:35:38 +0400
Subject: [Moscow.pm] =?utf-8?b?0J7RgtC60LvRjtGH0LXQvdC40LUgd2FybmluZ3Mg?=
 =?utf-8?q?=27uninitialized=27?=
In-Reply-To: <CANh0x-wPkUofkHAjxQCWcaHHyp5DaV9_RsdZ1fnpaUpjC-xfYw@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<CALE3dTUiM6XuPGVFMuPVLVZb9hO2rZ4ff8JgMsBF4dT=BAyWCg@mail.gmail.com>
	<CANh0x-xLAFRa-LoPsL1-Vd7hVvi-mU05B64uqkKBmyuyDzSHQA@mail.gmail.com>
	<20111028114917.GY24610@rabbit.us>
	<CANh0x-yHG9Y+4xygW3SVLm9-sfZNCdabJAsLHBON0Vt3V8su5A@mail.gmail.com>
	<58CAA63A-2D18-4F3C-B382-F89BF74EF33E@rambler-co.ru>
	<CANh0x-wPkUofkHAjxQCWcaHHyp5DaV9_RsdZ1fnpaUpjC-xfYw@mail.gmail.com>
Message-ID: <F6439B99-D70B-4BF6-B719-19BFB10A918B@rambler-co.ru>


On 29.10.2011, at 0:43, Ilya Chesnokov wrote:

> 29 октября 2011 г. 0:00 пользователь Mons Anderson <mons на rambler-co.ru> написал:
>> Попробую ответить зачем я так делаю.
> [skip]
>> TIMTOWTDI. Я пользуюсь тем, что удобно _мне_. Я рад, если кому-то еще это удобно. Я не буду вас убеждать, что вы пользуетесь чем-то неправильным только из-за того, что это неудобно, например, мне.
> 
> Спасибо за ответ.
> 
> Но с практической точки зрения я понял только то, что отключение
> предупреждений о неинициализированном значении -- это такая ловушка, о
> которой если ты помнишь, то будешь стараться покрывать свой код
> тестами и делать его максимально надежным и безопасным -- чтобы не
> сделать rmtree "$HOME/undef" -- хотя тут и warning не поможет. Если же
> ты при отключенных варнингах забудешь о дополнительных проверках --
> жди неприятностей.

В том и дело. Лишние defined ради устранения варнов замедляют код и делают его менее читабельным.
Просто warning не спасет от выполнения неправильного кода.
warnings fatal + uninitialized превращает перл в какое-то убожество.


> И ещё я понял, что Монс -- очень счастливый человек, раз может
> позволить себе программировать, так как удобно _ему_ :)) А не пытаться
> убедить свой рабочий коллектив, что и _им_ тоже будет так удобнее ;))

))

Вообще uni::perl был поддержан на ура в нескольких командах. Хотя я писал его по сути просто для себя дабы избавиться от большой кучи дефолтных юзов.


> 
> -- 
> Best regards,
> Ilya Chesnokov
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org


From mons на rambler-co.ru  Fri Oct 28 16:52:22 2011
From: mons на rambler-co.ru (Mons Anderson)
Date: Sat, 29 Oct 2011 03:52:22 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <20111028115949.GZ24610@rabbit.us>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
	<20111028115949.GZ24610@rabbit.us>
Message-ID: <22C06B3C-76F7-4DC3-AAD1-7C426D734527@rambler-co.ru>

Кстати мы с vovkasm патчили Class::Accessor::Grouped по аналогии с Class::XSaccessor.
Ускоряло работу DBIC в несколько раз.
так что в итоге производительность вполне приближалась к DBI.

Кстати еще в тему DBIC:
у нас на проекте есть десятки различных выборок. некоторые делаются из одной таблицы с разными join'ами и разными условиями, некоторые из другой, но к ней join'ится первая таблица.
так вот нам понадобилось сделать запрос, который выбрал бы предыдущий и следующий элемент из текущей выборки (resultset'a), относительно текущего.

используя DBIC эта задача была вполне решаема, т.к. весь запрос представлен в виде объекта и параметров и мы можем полностью проанализировать из чего он состоит и модифицировать его.
В случае использования raw DBI на N выборок пришлось бы писать 2N запросов на предыдущий/следующий элемент. И при модификации одного из запросов менять соответственно другие 2.

Так что при том, что DBIC это оверхед - это порой вполне оправданый оверхед.
Хотя я не спорю с тем, что на каких-то highload проектах мы отказыаваемся от DBIC в пользу чистого DBI.
Хотя на стадии прототипизации DBIC вполне приемлем т.к. сильно упрощает разработку.

On 28.10.2011, at 15:59, Peter Rabbitson wrote:

> On Fri, Oct 28, 2011 at 01:51:00PM +0200, Andrei wrote:
>> 28 октября 2011 г. 13:35 пользователь Евгений Торопов <jt на aaanet.ru>написал:
>> 
>>> On Oct 28, 2011, at 3:11 PM, Andrei wrote:
>>> 
>>> 28 октября 2011 г. 13:08 пользователь Ivan Petrov <i.petro.77.00 на gmail.com
>>>> написал:
>>> 
>>>>> Твой аргумент какой то дикий - разница м/у DBIC и писать ручками SQL
>>>>> подобна той между Perl и писать ручками assembler. Тебе Perl часом не
>>>>> мешает?
>>>> 
>>>> неуместное сравнение.
>>>> 
>>>> говорить о DBIC vs писать SQL ручками вообще нельзя. ибо DBIC умеет
>>>> составлять только самые простые запросы.
>>>> 
>>>> а на реальных задачах получаются либо извращения (вроде специальные
>>>> VIEW'ы дабы DBIC в них смотрел и не пытался самостоятельничать), либо
>>>> те же запросы ручками
>>>> 
>>> 
>>> 
>>> DBIC автоматизиреут наиболее частые простые задачи.
>>> 
>>> 
>>> Наиболее частые простые задачи автоматизируются примитивнейшими
>>> sql-генераторами и не стоят того, чтоб иметь пиздец какой оверхед (
>>> http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/03/benchmarking-dbixclass-vs-plain-dbi-on-hailo.html ).
>>> Если бенчмарки по ссылке устарели - покажите новые.
>>> 
>>> 
>> Вы бы Айвара до конца читали. А там написано:
>> 
> 
> А зачем мне его читать, когда я с ним лично говорил пока он замеры проводил :)
> Я ктому ответил что "Да, у DBIC узких мест полно, о них знаем, над ними
> работаем и если надо прямо чтоб сегодня быстро - надо так (->cursor)"
> 
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org


From mons на rambler-co.ru  Fri Oct 28 16:59:50 2011
From: mons на rambler-co.ru (Mons Anderson)
Date: Sat, 29 Oct 2011 03:59:50 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <CAKb9G9gFJhBrddvXm9hBwYcX2FPoEoyZLTLTj6haPwKEEB+42g@mail.gmail.com>
References: <CAKb9G9gFJhBrddvXm9hBwYcX2FPoEoyZLTLTj6haPwKEEB+42g@mail.gmail.com>
Message-ID: <6230E835-C5C9-4DDB-B2BF-5A4C2F5E8B0C@rambler-co.ru>

Увидел-бы такое, уволил бы сразу за некомпетентность.
Под апачом запускайте такую прелесть. Не понимаете сути асинхронных процессов - не лезьте в nginx с попыткой там что-то запрогать на перле.

On 28.10.2011, at 15:43, Alexandr Gomoliako wrote:

> On 10/28/11, Peter Vereshagin <peter на vereshagin.org> wrote:
>>> Разработка -- супер быстро, берете встроенный перл в nginx, JSON::XS
>>> смотрите в $r->uri и генерите запросы к DBI, легко. К тому же ответы через
> 
>> это может быть рекомендовано?
> 
>> Есть мнение что пока встроенный perl в nginx блокируется, например, ждёт
>> ответа из DBI, nginx хуже или вообще не отвечает остальным клиентам
>> и т. о. perl встроенный в nginx для такого в общем случае не предназначен.
> 
> Вообще не отвечает, остальные ждут. Но можно запустить больше
> воркеров и все станет хорошо. Т.е. вполне предназначен.
> Да и nginx блокируется много где: на чтении файлов, директорий,
> уменьшении картинок, генерации xslt, так что блокирование вообще
> не проблема.
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org


From zzz на zzz.org.ua  Fri Oct 28 17:07:11 2011
From: zzz на zzz.org.ua (Alexandr Gomoliako)
Date: Sat, 29 Oct 2011 03:07:11 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
	=?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <6230E835-C5C9-4DDB-B2BF-5A4C2F5E8B0C@rambler-co.ru>
References: <CAKb9G9gFJhBrddvXm9hBwYcX2FPoEoyZLTLTj6haPwKEEB+42g@mail.gmail.com>
	<6230E835-C5C9-4DDB-B2BF-5A4C2F5E8B0C@rambler-co.ru>
Message-ID: <CAKb9G9gfcsmO2oNL2cvCED6pHL0zU+nns-VyGJLSU+ynp-tKmg@mail.gmail.com>

On Sat, Oct 29, 2011 at 2:59 AM, Mons Anderson <mons на rambler-co.ru> wrote:
> Увидел-бы такое, уволил бы сразу за некомпетентность.
> Под апачом запускайте такую прелесть. Не понимаете сути асинхронных процессов - не лезьте в nginx с попыткой там что-то запрогать на перле.

Вот вы сейчас проявляете полнейшую некомпетентность.
Напишите, что вам не ясно, объясню.

From yu.pats на gmail.com  Fri Oct 28 17:09:27 2011
From: yu.pats на gmail.com (Yury Pats)
Date: Sat, 29 Oct 2011 03:09:27 +0300
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <CAKb9G9gfcsmO2oNL2cvCED6pHL0zU+nns-VyGJLSU+ynp-tKmg@mail.gmail.com>
References: <CAKb9G9gFJhBrddvXm9hBwYcX2FPoEoyZLTLTj6haPwKEEB+42g@mail.gmail.com>
	<6230E835-C5C9-4DDB-B2BF-5A4C2F5E8B0C@rambler-co.ru>
	<CAKb9G9gfcsmO2oNL2cvCED6pHL0zU+nns-VyGJLSU+ynp-tKmg@mail.gmail.com>
Message-ID: <CAFtO3fk=MraZ9xSQRUmEhvXkYfQec3CHq+XGQ_5En9QiR5t9Rg@mail.gmail.com>

2011/10/29 Alexandr Gomoliako <zzz на zzz.org.ua>:
> On Sat, Oct 29, 2011 at 2:59 AM, Mons Anderson <mons на rambler-co.ru> wrote:
>> Увидел-бы такое, уволил бы сразу за некомпетентность.
>> Под апачом запускайте такую прелесть. Не понимаете сути асинхронных процессов - не лезьте в nginx с попыткой там что-то запрогать на перле.
>
> Вот вы сейчас проявляете полнейшую некомпетентность.
> Напишите, что вам не ясно, объясню.

LOL


-- 
WBR, Yury Pats
skype: yuripats
cellular: +375 (29) 5870723

From zzz на zzz.org.ua  Fri Oct 28 17:48:33 2011
From: zzz на zzz.org.ua (Alexandr Gomoliako)
Date: Sat, 29 Oct 2011 03:48:33 +0300
Subject: [Moscow.pm]
	=?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
	=?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <CAFtO3fk=MraZ9xSQRUmEhvXkYfQec3CHq+XGQ_5En9QiR5t9Rg@mail.gmail.com>
References: <CAKb9G9gFJhBrddvXm9hBwYcX2FPoEoyZLTLTj6haPwKEEB+42g@mail.gmail.com>
	<6230E835-C5C9-4DDB-B2BF-5A4C2F5E8B0C@rambler-co.ru>
	<CAKb9G9gfcsmO2oNL2cvCED6pHL0zU+nns-VyGJLSU+ynp-tKmg@mail.gmail.com>
	<CAFtO3fk=MraZ9xSQRUmEhvXkYfQec3CHq+XGQ_5En9QiR5t9Rg@mail.gmail.com>
Message-ID: <CAKb9G9h2buQbb7ozQ=3DU6Jc25NkEp3hyruAnKbhp2HZkaMbZA@mail.gmail.com>

On Sat, Oct 29, 2011 at 3:09 AM, Yury Pats <yu.pats на gmail.com> wrote:
> 2011/10/29 Alexandr Gomoliako <zzz на zzz.org.ua>:
>> On Sat, Oct 29, 2011 at 2:59 AM, Mons Anderson <mons на rambler-co.ru> wrote:
>>> Увидел-бы такое, уволил бы сразу за некомпетентность.
>>> Под апачом запускайте такую прелесть. Не понимаете сути асинхронных процессов - не лезьте в nginx с попыткой там что-то запрогать на перле.
>>
>> Вот вы сейчас проявляете полнейшую некомпетентность.
>> Напишите, что вам не ясно, объясню.
>
> LOL

Чего LOL? Я серьезно. А то такое заявлять, еще и с rambler-co.ru.
Рамблеру должно быть очень стыдно.

From rabbit+moscowpm на rabbit.us  Fri Oct 28 19:09:30 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Fri, 28 Oct 2011 22:09:30 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <22C06B3C-76F7-4DC3-AAD1-7C426D734527@rambler-co.ru>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
	<20111028115949.GZ24610@rabbit.us>
	<22C06B3C-76F7-4DC3-AAD1-7C426D734527@rambler-co.ru>
Message-ID: <20111029020930.GA24861@rabbit.us>

On Sat, Oct 29, 2011 at 03:52:22AM +0400, Mons Anderson wrote:
> Кстати мы с vovkasm патчили Class::Accessor::Grouped по аналогии с Class::XSaccessor.
> Ускоряло работу DBIC в несколько раз.
> так что в итоге производительность вполне приближалась к DBI.
> 

Патчи в студию!

From akovbovich на gmail.com  Fri Oct 28 19:30:37 2011
From: akovbovich на gmail.com (=?UTF-8?B?0JDQvdC00YDQtdC5INCfLiDQmtC+0LLQsdC+0LLQuNGH?=)
Date: Sat, 29 Oct 2011 06:30:37 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <CAKb9G9h2buQbb7ozQ=3DU6Jc25NkEp3hyruAnKbhp2HZkaMbZA@mail.gmail.com>
References: <CAKb9G9gFJhBrddvXm9hBwYcX2FPoEoyZLTLTj6haPwKEEB+42g@mail.gmail.com>
	<6230E835-C5C9-4DDB-B2BF-5A4C2F5E8B0C@rambler-co.ru>
	<CAKb9G9gfcsmO2oNL2cvCED6pHL0zU+nns-VyGJLSU+ynp-tKmg@mail.gmail.com>
	<CAFtO3fk=MraZ9xSQRUmEhvXkYfQec3CHq+XGQ_5En9QiR5t9Rg@mail.gmail.com>
	<CAKb9G9h2buQbb7ozQ=3DU6Jc25NkEp3hyruAnKbhp2HZkaMbZA@mail.gmail.com>
Message-ID: <CAPTWO-Y3FeY24=pF=jZO6MGZBZ1BiAmK+t0nqhONG+347wq=ZQ@mail.gmail.com>

еще одна бугагашенька)

29 октября 2011 г. 4:48 пользователь Alexandr Gomoliako
<zzz на zzz.org.ua> написал:
> On Sat, Oct 29, 2011 at 3:09 AM, Yury Pats <yu.pats на gmail.com> wrote:
>> 2011/10/29 Alexandr Gomoliako <zzz на zzz.org.ua>:
>>> On Sat, Oct 29, 2011 at 2:59 AM, Mons Anderson <mons на rambler-co.ru> wrote:
>>>> Увидел-бы такое, уволил бы сразу за некомпетентность.
>>>> Под апачом запускайте такую прелесть. Не понимаете сути асинхронных процессов - не лезьте в nginx с попыткой там что-то запрогать на перле.
>>>
>>> Вот вы сейчас проявляете полнейшую некомпетентность.
>>> Напишите, что вам не ясно, объясню.
>>
>> LOL
>
> Чего LOL? Я серьезно. А то такое заявлять, еще и с rambler-co.ru.
> Рамблеру должно быть очень стыдно.
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>

From somerandomlogin на gmail.com  Fri Oct 28 22:25:00 2011
From: somerandomlogin на gmail.com (Jack of Shadows)
Date: Sat, 29 Oct 2011 09:25:00 +0400
Subject: [Moscow.pm]
	=?koi8-r?b?1NTU1CBbIMHNTW9zY293LnBtXSDywdrN2dvMxc7J?=
	=?koi8-r?b?0SDOwSDUxc3VIE9STSDJINfPz8LdxcPL1SDSwcLPxczN1NkgzSDF?=
	=?koi8-r?b?IMEuzMEgdXVva2xmaWZmZmZmZmZ5aWZ1ZmZmZmZmZmZmdXV1ZmZm?=
	=?koi8-r?b?dWZjZmh2ZmdoY2dmdWZpZmZmZnVoaHBwb29vcGxta2Zm0yDi5A==?=
In-Reply-To: <CAME9Y=59g_NZnrPatjDHcv6=sRYS4D54K8h-_OZ1cMmCXFJ73g@mail.gmail.com>
References: <jjxetxmywty3ciy1gi0ahfpx.1319793579655@email.android.com>
	<CAME9Y=59g_NZnrPatjDHcv6=sRYS4D54K8h-_OZ1cMmCXFJ73g@mail.gmail.com>
Message-ID: <CAH1e3-d4mS6Qhmma_wUR69tNV-LW7Qn=3zu0_MEY5p6MgsrCRQ@mail.gmail.com>

Присоединяюсь. Именно так всё и есть. :-)

2011/10/28 Андрей Костенко <andrey на kostenko.name>:
> Вот именно!
>
> 2011/10/28 Ivan Panchenko <ivan на stack.net>
>>
>> Lolllb
>> Fpkppbubbp
>>
>> Михаил Шогин <mshogin на gmail.com> написал(а):
>>
>> >>
>> >> > Мда, долгая дискуссия.
>> >> >
>> >> > ORM - зло!
>> >> >
>> >> > Что такое SQL ( в простом определении ) - это то что мы хотим
>> >> > получить и
>> >> > ПУТЬ получения данных.
>> >> > При использовании ORM и конструкторов запросов, мы не черта не знаем
>> >> каким
>> >> > путем мы получаем данные, а это самое главное.
>> >> > Как оптимизировать запросы? Как закреплять планы выполнения?
>> >> > Ведь в каком то случае лучше использовать HASH JOIN, а в каком то
>> >> > NESTED
>> >> > LOOP.
>> >> >
>> >> > Даже банальная фильтрация данных может идти несколькими различными
>> >> путями:
>> >> >  - table full scan
>> >> >  - index range scan + table access by rowid
>> >> >  - index range scan
>> >> >  - index full scan
>> >> >
>> >> > Как всем этим управлять?
>> >>
>> >> Фишка здесь в том что такой микроскоп нужен на 1 из 100 запросов.
>> >> Хватай
>> >> голый $dbh из DBIC и делай что хочеш. Ведь нигде не сказано что раз
>> >> DBIC
>> >> так всегда DBIC. Надо все таки уметь сообразить когда пора положить
>> >> молоток
>> >> и взять отвертку :)
>> >>
>> >
>> >Хех, нет, у нас не так. Запросы оптимизируются перед использованием в
>> > коде.
>> >+ выставляются хинты для быстрого выявления тормозных запросов.
>> >
>> >
>> >
>> >--
>> >С уважением
>> >Михаил Шогин.
>> >Tel: +7 915 0311328
>> >ICQ: 266776394
>> >
>> >--
>> >Moscow.pm mailing list
>> >moscow-pm на pm.org | http://moscow.pm.org
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>

From jt на aaanet.ru  Sat Oct 29 01:12:31 2011
From: jt на aaanet.ru (=?utf-8?B?0JXQstCz0LXQvdC40Lkg0KLQvtGA0L7Qv9C+0LI=?=)
Date: Sat, 29 Oct 2011 12:12:31 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <22C06B3C-76F7-4DC3-AAD1-7C426D734527@rambler-co.ru>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
	<20111028115949.GZ24610@rabbit.us>
	<22C06B3C-76F7-4DC3-AAD1-7C426D734527@rambler-co.ru>
Message-ID: <D86EF836-B347-4969-8D17-EF604DDF0EF9@aaanet.ru>

Патч интересно было бы посмотреть, да, а вот про пред/след - че-то не понял я, почему via DBIC можно модифицировать запрос, а via DBI / sql-генератор нет

On Oct 29, 2011, at 3:52 AM, Mons Anderson wrote:

> Кстати мы с vovkasm патчили Class::Accessor::Grouped по аналогии с Class::XSaccessor.
> Ускоряло работу DBIC в несколько раз.
> так что в итоге производительность вполне приближалась к DBI.
> 
> Кстати еще в тему DBIC:
> у нас на проекте есть десятки различных выборок. некоторые делаются из одной таблицы с разными join'ами и разными условиями, некоторые из другой, но к ней join'ится первая таблица.
> так вот нам понадобилось сделать запрос, который выбрал бы предыдущий и следующий элемент из текущей выборки (resultset'a), относительно текущего.
> 
> используя DBIC эта задача была вполне решаема, т.к. весь запрос представлен в виде объекта и параметров и мы можем полностью проанализировать из чего он состоит и модифицировать его.
> В случае использования raw DBI на N выборок пришлось бы писать 2N запросов на предыдущий/следующий элемент. И при модификации одного из запросов менять соответственно другие 2.
> 
> Так что при том, что DBIC это оверхед - это порой вполне оправданый оверхед.
> Хотя я не спорю с тем, что на каких-то highload проектах мы отказыаваемся от DBIC в пользу чистого DBI.
> Хотя на стадии прототипизации DBIC вполне приемлем т.к. сильно упрощает разработку.
> 
> On 28.10.2011, at 15:59, Peter Rabbitson wrote:
> 
>> On Fri, Oct 28, 2011 at 01:51:00PM +0200, Andrei wrote:
>>> 28 октября 2011 г. 13:35 пользователь Евгений Торопов <jt на aaanet.ru>написал:
>>> 
>>>> On Oct 28, 2011, at 3:11 PM, Andrei wrote:
>>>> 
>>>> 28 октября 2011 г. 13:08 пользователь Ivan Petrov <i.petro.77.00 на gmail.com
>>>>> написал:
>>>> 
>>>>>> Твой аргумент какой то дикий - разница м/у DBIC и писать ручками SQL
>>>>>> подобна той между Perl и писать ручками assembler. Тебе Perl часом не
>>>>>> мешает?
>>>>> 
>>>>> неуместное сравнение.
>>>>> 
>>>>> говорить о DBIC vs писать SQL ручками вообще нельзя. ибо DBIC умеет
>>>>> составлять только самые простые запросы.
>>>>> 
>>>>> а на реальных задачах получаются либо извращения (вроде специальные
>>>>> VIEW'ы дабы DBIC в них смотрел и не пытался самостоятельничать), либо
>>>>> те же запросы ручками
>>>>> 
>>>> 
>>>> 
>>>> DBIC автоматизиреут наиболее частые простые задачи.
>>>> 
>>>> 
>>>> Наиболее частые простые задачи автоматизируются примитивнейшими
>>>> sql-генераторами и не стоят того, чтоб иметь пиздец какой оверхед (
>>>> http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/03/benchmarking-dbixclass-vs-plain-dbi-on-hailo.html ).
>>>> Если бенчмарки по ссылке устарели - покажите новые.
>>>> 
>>>> 
>>> Вы бы Айвара до конца читали. А там написано:
>>> 
>> 
>> А зачем мне его читать, когда я с ним лично говорил пока он замеры проводил :)
>> Я ктому ответил что "Да, у DBIC узких мест полно, о них знаем, над ними
>> работаем и если надо прямо чтоб сегодня быстро - надо так (->cursor)"
>> 
>> -- 
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
> 
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org


From mons на rambler-co.ru  Sat Oct 29 04:27:39 2011
From: mons на rambler-co.ru (Mons Anderson)
Date: Sat, 29 Oct 2011 15:27:39 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <D86EF836-B347-4969-8D17-EF604DDF0EF9@aaanet.ru>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
	<20111028115949.GZ24610@rabbit.us>
	<22C06B3C-76F7-4DC3-AAD1-7C426D734527@rambler-co.ru>
	<D86EF836-B347-4969-8D17-EF604DDF0EF9@aaanet.ru>
Message-ID: <5E887940-C8D2-4B90-A47A-C5E1AFAAAFF6@rambler-co.ru>

Задача:

1. Есть некий сложный resultset (joins, filters, order by).
2. Есть id одной строки, который заведомо входит в этот resultset.
нужно выбрать еще 2 строки: ту, которая идет перед этим id и после него.

Пример псевдозапроса, генерируемого resultset'ом:
select * from photos join users join likes where photo.access > 2 and photo.album = 10 order by likes desc, photo.id asc

Попробуйте ее решить.
В понедельник кину более детальный пример с решением и объяснением.

On 29.10.2011, at 12:12, Евгений Торопов wrote:

> Патч интересно было бы посмотреть, да, а вот про пред/след - че-то не понял я, почему via DBIC можно модифицировать запрос, а via DBI / sql-генератор нет
> 
> On Oct 29, 2011, at 3:52 AM, Mons Anderson wrote:
> 
>> Кстати мы с vovkasm патчили Class::Accessor::Grouped по аналогии с Class::XSaccessor.
>> Ускоряло работу DBIC в несколько раз.
>> так что в итоге производительность вполне приближалась к DBI.
>> 
>> Кстати еще в тему DBIC:
>> у нас на проекте есть десятки различных выборок. некоторые делаются из одной таблицы с разными join'ами и разными условиями, некоторые из другой, но к ней join'ится первая таблица.
>> так вот нам понадобилось сделать запрос, который выбрал бы предыдущий и следующий элемент из текущей выборки (resultset'a), относительно текущего.
>> 
>> используя DBIC эта задача была вполне решаема, т.к. весь запрос представлен в виде объекта и параметров и мы можем полностью проанализировать из чего он состоит и модифицировать его.
>> В случае использования raw DBI на N выборок пришлось бы писать 2N запросов на предыдущий/следующий элемент. И при модификации одного из запросов менять соответственно другие 2.
>> 
>> Так что при том, что DBIC это оверхед - это порой вполне оправданый оверхед.
>> Хотя я не спорю с тем, что на каких-то highload проектах мы отказыаваемся от DBIC в пользу чистого DBI.
>> Хотя на стадии прототипизации DBIC вполне приемлем т.к. сильно упрощает разработку.
>> 
>> On 28.10.2011, at 15:59, Peter Rabbitson wrote:
>> 
>>> On Fri, Oct 28, 2011 at 01:51:00PM +0200, Andrei wrote:
>>>> 28 октября 2011 г. 13:35 пользователь Евгений Торопов <jt на aaanet.ru>написал:
>>>> 
>>>>> On Oct 28, 2011, at 3:11 PM, Andrei wrote:
>>>>> 
>>>>> 28 октября 2011 г. 13:08 пользователь Ivan Petrov <i.petro.77.00 на gmail.com
>>>>>> написал:
>>>>> 
>>>>>>> Твой аргумент какой то дикий - разница м/у DBIC и писать ручками SQL
>>>>>>> подобна той между Perl и писать ручками assembler. Тебе Perl часом не
>>>>>>> мешает?
>>>>>> 
>>>>>> неуместное сравнение.
>>>>>> 
>>>>>> говорить о DBIC vs писать SQL ручками вообще нельзя. ибо DBIC умеет
>>>>>> составлять только самые простые запросы.
>>>>>> 
>>>>>> а на реальных задачах получаются либо извращения (вроде специальные
>>>>>> VIEW'ы дабы DBIC в них смотрел и не пытался самостоятельничать), либо
>>>>>> те же запросы ручками
>>>>>> 
>>>>> 
>>>>> 
>>>>> DBIC автоматизиреут наиболее частые простые задачи.
>>>>> 
>>>>> 
>>>>> Наиболее частые простые задачи автоматизируются примитивнейшими
>>>>> sql-генераторами и не стоят того, чтоб иметь пиздец какой оверхед (
>>>>> http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/03/benchmarking-dbixclass-vs-plain-dbi-on-hailo.html ).
>>>>> Если бенчмарки по ссылке устарели - покажите новые.
>>>>> 
>>>>> 
>>>> Вы бы Айвара до конца читали. А там написано:
>>>> 
>>> 
>>> А зачем мне его читать, когда я с ним лично говорил пока он замеры проводил :)
>>> Я ктому ответил что "Да, у DBIC узких мест полно, о них знаем, над ними
>>> работаем и если надо прямо чтоб сегодня быстро - надо так (->cursor)"
>>> 
>>> -- 
>>> Moscow.pm mailing list
>>> moscow-pm на pm.org | http://moscow.pm.org
>> 
>> -- 
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
> 
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org


From mons на rambler-co.ru  Sat Oct 29 04:28:09 2011
From: mons на rambler-co.ru (Mons Anderson)
Date: Sat, 29 Oct 2011 15:28:09 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <20111029020930.GA24861@rabbit.us>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
	<20111028115949.GZ24610@rabbit.us>
	<22C06B3C-76F7-4DC3-AAD1-7C426D734527@rambler-co.ru>
	<20111029020930.GA24861@rabbit.us>
Message-ID: <E440520D-6A6C-427E-AE1C-30569F9C1418@rambler-co.ru>

Поищу )

On 29.10.2011, at 6:09, Peter Rabbitson wrote:

> On Sat, Oct 29, 2011 at 03:52:22AM +0400, Mons Anderson wrote:
>> Кстати мы с vovkasm патчили Class::Accessor::Grouped по аналогии с Class::XSaccessor.
>> Ускоряло работу DBIC в несколько раз.
>> так что в итоге производительность вполне приближалась к DBI.
>> 
> 
> Патчи в студию!
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org


From akzhan.abdulin на gmail.com  Sat Oct 29 06:23:51 2011
From: akzhan.abdulin на gmail.com (Akzhan Abdulin)
Date: Sat, 29 Oct 2011 17:23:51 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <5E887940-C8D2-4B90-A47A-C5E1AFAAAFF6@rambler-co.ru>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
	<20111028115949.GZ24610@rabbit.us>
	<22C06B3C-76F7-4DC3-AAD1-7C426D734527@rambler-co.ru>
	<D86EF836-B347-4969-8D17-EF604DDF0EF9@aaanet.ru>
	<5E887940-C8D2-4B90-A47A-C5E1AFAAAFF6@rambler-co.ru>
Message-ID: <CAGOcgF0wNg2QeY5aOoD8XmtbXQACh4NH9H3k23LNQtfytu2WdQ@mail.gmail.com>

Ну это тривиально. Например, через подзапрос. А можно через объединение.
Можно все вместе сразу вытащить.

29 октября 2011 г. 15:27 пользователь Mons Anderson <mons на rambler-co.ru>написал:

> Задача:
>
> 1. Есть некий сложный resultset (joins, filters, order by).
> 2. Есть id одной строки, который заведомо входит в этот resultset.
> нужно выбрать еще 2 строки: ту, которая идет перед этим id и после него.
>
> Пример псевдозапроса, генерируемого resultset'ом:
> select * from photos join users join likes where photo.access > 2 and
> photo.album = 10 order by likes desc, photo.id asc
>
> Попробуйте ее решить.
> В понедельник кину более детальный пример с решением и объяснением.
>
> On 29.10.2011, at 12:12, Евгений Торопов wrote:
>
> > Патч интересно было бы посмотреть, да, а вот про пред/след - че-то не
> понял я, почему via DBIC можно модифицировать запрос, а via DBI /
> sql-генератор нет
> >
> > On Oct 29, 2011, at 3:52 AM, Mons Anderson wrote:
> >
> >> Кстати мы с vovkasm патчили Class::Accessor::Grouped по аналогии с
> Class::XSaccessor.
> >> Ускоряло работу DBIC в несколько раз.
> >> так что в итоге производительность вполне приближалась к DBI.
> >>
> >> Кстати еще в тему DBIC:
> >> у нас на проекте есть десятки различных выборок. некоторые делаются из
> одной таблицы с разными join'ами и разными условиями, некоторые из другой,
> но к ней join'ится первая таблица.
> >> так вот нам понадобилось сделать запрос, который выбрал бы предыдущий и
> следующий элемент из текущей выборки (resultset'a), относительно текущего.
> >>
> >> используя DBIC эта задача была вполне решаема, т.к. весь запрос
> представлен в виде объекта и параметров и мы можем полностью
> проанализировать из чего он состоит и модифицировать его.
> >> В случае использования raw DBI на N выборок пришлось бы писать 2N
> запросов на предыдущий/следующий элемент. И при модификации одного из
> запросов менять соответственно другие 2.
> >>
> >> Так что при том, что DBIC это оверхед - это порой вполне оправданый
> оверхед.
> >> Хотя я не спорю с тем, что на каких-то highload проектах мы
> отказыаваемся от DBIC в пользу чистого DBI.
> >> Хотя на стадии прототипизации DBIC вполне приемлем т.к. сильно упрощает
> разработку.
> >>
> >> On 28.10.2011, at 15:59, Peter Rabbitson wrote:
> >>
> >>> On Fri, Oct 28, 2011 at 01:51:00PM +0200, Andrei wrote:
> >>>> 28 октября 2011 г. 13:35 пользователь Евгений Торопов <jt на aaanet.ru
> >написал:
> >>>>
> >>>>> On Oct 28, 2011, at 3:11 PM, Andrei wrote:
> >>>>>
> >>>>> 28 октября 2011 г. 13:08 пользователь Ivan Petrov <
> i.petro.77.00 на gmail.com
> >>>>>> написал:
> >>>>>
> >>>>>>> Твой аргумент какой то дикий - разница м/у DBIC и писать ручками
> SQL
> >>>>>>> подобна той между Perl и писать ручками assembler. Тебе Perl часом
> не
> >>>>>>> мешает?
> >>>>>>
> >>>>>> неуместное сравнение.
> >>>>>>
> >>>>>> говорить о DBIC vs писать SQL ручками вообще нельзя. ибо DBIC умеет
> >>>>>> составлять только самые простые запросы.
> >>>>>>
> >>>>>> а на реальных задачах получаются либо извращения (вроде специальные
> >>>>>> VIEW'ы дабы DBIC в них смотрел и не пытался самостоятельничать),
> либо
> >>>>>> те же запросы ручками
> >>>>>>
> >>>>>
> >>>>>
> >>>>> DBIC автоматизиреут наиболее частые простые задачи.
> >>>>>
> >>>>>
> >>>>> Наиболее частые простые задачи автоматизируются примитивнейшими
> >>>>> sql-генераторами и не стоят того, чтоб иметь пиздец какой оверхед (
> >>>>>
> http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/03/benchmarking-dbixclass-vs-plain-dbi-on-hailo.html).
> >>>>> Если бенчмарки по ссылке устарели - покажите новые.
> >>>>>
> >>>>>
> >>>> Вы бы Айвара до конца читали. А там написано:
> >>>>
> >>>
> >>> А зачем мне его читать, когда я с ним лично говорил пока он замеры
> проводил :)
> >>> Я ктому ответил что "Да, у DBIC узких мест полно, о них знаем, над ними
> >>> работаем и если надо прямо чтоб сегодня быстро - надо так (->cursor)"
> >>>
> >>> --
> >>> Moscow.pm mailing list
> >>> moscow-pm на pm.org | http://moscow.pm.org
> >>
> >> --
> >> Moscow.pm mailing list
> >> moscow-pm на pm.org | http://moscow.pm.org
> >
> > --
> > Moscow.pm mailing list
> > moscow-pm на pm.org | http://moscow.pm.org
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111029/7df74de0/attachment-0001.html>

From postmaster на softsearch.ru  Sat Oct 29 11:18:05 2011
From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=)
Date: Sat, 29 Oct 2011 22:18:05 +0400
Subject: [Moscow.pm] =?koi8-r?b?6c3FzsEgy8zB09TF0s/XLg==?=
Message-ID: <1367200608.20111029221805@softsearch.ru>

Здравствуйте.

Может кто знает алгоритмы поиска названий кластеров, когда на кластеры
разбиваются текстовые документы?

-- 
С уважением,
 Михаил                          mailto:postmaster на softsearch.ru


From andy на shitov.ru  Sat Oct 29 12:47:10 2011
From: andy на shitov.ru (Andrew Shitov)
Date: Sat, 29 Oct 2011 21:47:10 +0200
Subject: [Moscow.pm] Saint Perl - 3
In-Reply-To: <CAMOxC8uQSytpLFGhTbZhMmHK5-AqRmAz7pYo+TA45MTz7D1ZyQ@mail.gmail.com>
References: <CANTXRvRjGu1jFwNMR0LJi1Ku-xiUbHRMUs3P247L5g-_px+vHg@mail.gmail.com>
	<CAMOxC8uQSytpLFGhTbZhMmHK5-AqRmAz7pYo+TA45MTz7D1ZyQ@mail.gmail.com>
Message-ID: <CANTXRvTkK7HHDX6BQDnRnhreq7_VvUB=NdxdY2RgZOGfZHYqOQ@mail.gmail.com>

> А где venue?

Санкт-Петербург, пр. Обуховской обороны, д. 70, к. 2, ст. м. ?Елизаровская?.


-- 
Andrew Shitov
______________________________________________________________________
andy на shitov.ru | http://shitov.ru

From denis.fedoseev на gmail.com  Sat Oct 29 15:33:28 2011
From: denis.fedoseev на gmail.com (Denis Fedoseev)
Date: Sun, 30 Oct 2011 02:33:28 +0400
Subject: [Moscow.pm] Saint Perl - 3
In-Reply-To: <CANTXRvTkK7HHDX6BQDnRnhreq7_VvUB=NdxdY2RgZOGfZHYqOQ@mail.gmail.com>
References: <CANTXRvRjGu1jFwNMR0LJi1Ku-xiUbHRMUs3P247L5g-_px+vHg@mail.gmail.com>
	<CAMOxC8uQSytpLFGhTbZhMmHK5-AqRmAz7pYo+TA45MTz7D1ZyQ@mail.gmail.com>
	<CANTXRvTkK7HHDX6BQDnRnhreq7_VvUB=NdxdY2RgZOGfZHYqOQ@mail.gmail.com>
Message-ID: <3BD2F098-26A6-4C7A-BC0C-ECC94C76FB1D@gmail.com>

Это случайно не Ингрия?

On Oct 29, 2011, at 11:47 PM, Andrew Shitov wrote:

>> А где venue?
> 
> Санкт-Петербург, пр. Обуховской обороны, д. 70, к. 2, ст. м. ?Елизаровская?.
> 
> 
> -- 
> Andrew Shitov
> ______________________________________________________________________
> andy на shitov.ru | http://shitov.ru
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org


From andy на shitov.ru  Sun Oct 30 00:18:03 2011
From: andy на shitov.ru (Andrew Shitov)
Date: Sun, 30 Oct 2011 08:18:03 +0100
Subject: [Moscow.pm] Saint Perl - 3
In-Reply-To: <3BD2F098-26A6-4C7A-BC0C-ECC94C76FB1D@gmail.com>
References: <CANTXRvRjGu1jFwNMR0LJi1Ku-xiUbHRMUs3P247L5g-_px+vHg@mail.gmail.com>
	<CAMOxC8uQSytpLFGhTbZhMmHK5-AqRmAz7pYo+TA45MTz7D1ZyQ@mail.gmail.com>
	<CANTXRvTkK7HHDX6BQDnRnhreq7_VvUB=NdxdY2RgZOGfZHYqOQ@mail.gmail.com>
	<3BD2F098-26A6-4C7A-BC0C-ECC94C76FB1D@gmail.com>
Message-ID: <CANTXRvSW=As7kg2JGtZSsmB3-mpA=spz2GccO+Wp62HSMCAekw@mail.gmail.com>

Ингрия.

2011/10/30 Denis Fedoseev <denis.fedoseev на gmail.com>:
> Это случайно не Ингрия?
>
> On Oct 29, 2011, at 11:47 PM, Andrew Shitov wrote:
>
>>> А где venue?
>>
>> Санкт-Петербург, пр. Обуховской обороны, д. 70, к. 2, ст. м. ?Елизаровская?.
>>
>>
>> --
>> Andrew Shitov
>> ______________________________________________________________________
>> andy на shitov.ru | http://shitov.ru
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
Andrew Shitov
______________________________________________________________________
andy на shitov.ru | http://shitov.ru

From grigory.sapunov на gmail.com  Sun Oct 30 02:47:05 2011
From: grigory.sapunov на gmail.com (Grigory V.Sapunov)
Date: Sun, 30 Oct 2011 13:47:05 +0400
Subject: [Moscow.pm] =?koi8-r?b?6c3FzsEgy8zB09TF0s/XLg==?=
In-Reply-To: <1367200608.20111029221805@softsearch.ru>
References: <1367200608.20111029221805@softsearch.ru>
Message-ID: <CAOZ5q3Nsb6U2CSjXUmpNNveCU9Wy6WpzhCxEnrOp_4dZEt_Sig@mail.gmail.com>

А какая конкретно задача? Этому целая область посвящена -- Multiple
Document Summarization.

Где-то для этого достаточно выбрать заголовок одного из документов,
где-то достаточно наиболее представительного тэга или именной группы,
а где-то нужно ещё и сделать обобщение, например, с использованием
тезаурусов и создать аннотацию, которая ни в каком конкретном
документе не содержится. Сложность соответственно тоже очень разная,
от простого подсчёта и выбора наиболее частотной сущности до сложных
алгоритмов машинного обучения с использованием лингвистического
обеспечения.

2011/10/29 Михаил Монашёв <postmaster на softsearch.ru>:
>
> Может кто знает алгоритмы поиска названий кластеров, когда на кластеры
> разбиваются текстовые документы?
>

From peter на vereshagin.org  Sun Oct 30 06:42:02 2011
From: peter на vereshagin.org (Peter Vereshagin)
Date: Sun, 30 Oct 2011 17:42:02 +0400
Subject: [Moscow.pm]
 =?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
 =?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <CAKb9G9gFJhBrddvXm9hBwYcX2FPoEoyZLTLTj6haPwKEEB+42g@mail.gmail.com>
Message-ID: <20111030134202.GA5746@external.screwed.box>

Hello.

2011/10/28 04:43:56 -0700 moscow-pm-request на pm.org => To moscow-pm на pm.org :

> >> Разработка -- супер быстро, берете встроенный перл в nginx, JSON::XS
> >> смотрите в $r->uri и генерите запросы к DBI, легко. К тому же ответы через
> 
> > это может быть рекомендовано?
> 
> > Есть мнение что пока встроенный perl в nginx блокируется, например, ждёт
> > ответа из DBI, nginx хуже или вообще не отвечает остальным клиентам
> > и т. о. perl встроенный в nginx для такого в общем случае не предназначен.
> 
> Вообще не отвечает, остальные ждут. Но можно запустить больше
> воркеров и все станет хорошо. Т.е. вполне предназначен.
> Да и nginx блокируется много где: на чтении файлов, директорий,
> уменьшении картинок, генерации xslt, так что блокирование вообще
> не проблема.

да ну ещё эти процессы пускать. psgi-бекенд лучше уж как-нибудь. хотя, может,
всё уже и изменилось, но что-то помню, что это было не лучшей практикой, могу
порыться и найти про это.

в любом случае, на бенчмарки бы позырил. Включая, например, под ms-win. Намедни
узнал, что там воркеров больше одного - хуже, чем когда один.

--
Peter Vereshagin <peter на vereshagin.org> (http://vereshagin.org) pgp: A0E26627 

From peter на vereshagin.org  Sun Oct 30 06:49:58 2011
From: peter на vereshagin.org (Peter Vereshagin)
Date: Sun, 30 Oct 2011 17:49:58 +0400
Subject: [Moscow.pm]
 =?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
 =?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <20111028020533.GA24610@rabbit.us>
Message-ID: <20111030134958.GB5746@external.screwed.box>

Hello.

2011/10/27 23:30:15 -0700 moscow-pm-request на pm.org => To moscow-pm на pm.org :

> А Moose каким боком связан с DBIC...?

Не помню, откуда взял, порылся --- слухи были

    http://www.perlmonks.org/?node_id=676518

    Re: ORM for Moose
    by stvn (Monsignor) on Mar 26, 2008 at 21:53 UTC
    
    As zby said, the next major DBIx::Class release will be (re)written in Moose. 

--
Peter Vereshagin <peter на vereshagin.org> (http://vereshagin.org) pgp: A0E26627 

From rabbit+moscowpm на rabbit.us  Sun Oct 30 07:03:17 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Sun, 30 Oct 2011 10:03:17 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <20111030134958.GB5746@external.screwed.box>
References: <20111028020533.GA24610@rabbit.us>
	<20111030134958.GB5746@external.screwed.box>
Message-ID: <20111030140317.GA2216@rabbit.us>

On Sun, Oct 30, 2011 at 05:49:58PM +0400, Peter Vereshagin wrote:
> Hello.
> 
> 2011/10/27 23:30:15 -0700 moscow-pm-request на pm.org => To moscow-pm на pm.org :
> 
> > А Moose каким боком связан с DBIC...?
> 
> Не помню, откуда взял, порылся --- слухи были
> 
>     http://www.perlmonks.org/?node_id=676518
> 
>     Re: ORM for Moose
>     by stvn (Monsignor) on Mar 26, 2008 at 21:53 UTC
>     
>     As zby said, the next major DBIx::Class release will be (re)written in Moose. 
> 

Слишком тяжело, так что слухи можно закопать. Некоторые части перейдут
потихоньку на Moo, но полного Moose там не будет очень долго, если вообще
когда будет. У меня к сожалению все никак не доходят руки написать
нормальный Vision-document, но опорные точки:

*) Perl 5.8 будет поддерживатся до тех пор пока не появятся непреодолимые
препядствия (какив кстати не предвидятся). Moose активно хочет от 5.8
отказатся.

*) DBIC должен быть App::FatPack-абле исключая сам DBI/DBD. Здесь не просто
"cool factor" - есть реальные выгоды, позволяющие нам делать некоторые вещи
о которых пока думать не можем. Весь XS который Moose за собой тащит мне
здесь мало нужен.

В итоге (по крайней мере пока я в проекте) DBIC и Moose ну просто никак не
по пути.

Cheers


From rabbit+moscowpm на rabbit.us  Sun Oct 30 07:30:36 2011
From: rabbit+moscowpm на rabbit.us (Peter Rabbitson)
Date: Sun, 30 Oct 2011 10:30:36 -0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <E440520D-6A6C-427E-AE1C-30569F9C1418@rambler-co.ru>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
	<20111028115949.GZ24610@rabbit.us>
	<22C06B3C-76F7-4DC3-AAD1-7C426D734527@rambler-co.ru>
	<20111029020930.GA24861@rabbit.us>
	<E440520D-6A6C-427E-AE1C-30569F9C1418@rambler-co.ru>
Message-ID: <20111030143035.GB2216@rabbit.us>

On Sat, Oct 29, 2011 at 03:28:09PM +0400, Mons Anderson wrote:
> Поищу )
> 

Обязательно поищи! Даже если не понравится, то доведем до ума и выложим
куда следует. Почему-то складывается впечатление что те которых скорость
волнует решили что с маинтаинерами нечего даже разговаривать. Мы тоже
люди, некоторые даже русские: тоже любим быстро ездить :)


From postmaster на softsearch.ru  Sun Oct 30 09:40:39 2011
From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=)
Date: Sun, 30 Oct 2011 20:40:39 +0400
Subject: [Moscow.pm] =?koi8-r?b?6c3FzsEgy8zB09TF0s/XLg==?=
In-Reply-To: <CAOZ5q3Nsb6U2CSjXUmpNNveCU9Wy6WpzhCxEnrOp_4dZEt_Sig@mail.gmail.com>
References: <1367200608.20111029221805@softsearch.ru>
	<CAOZ5q3Nsb6U2CSjXUmpNNveCU9Wy6WpzhCxEnrOp_4dZEt_Sig@mail.gmail.com>
Message-ID: <1015101794.20111030204039@softsearch.ru>

Здравствуйте, Grigory.

Я хотел теорию почитать.

> А какая конкретно задача? Этому целая область посвящена -- Multiple
> Document Summarization.

> Где-то для этого достаточно выбрать заголовок одного из документов,
> где-то достаточно наиболее представительного тэга или именной группы,
> а где-то нужно ещё и сделать обобщение, например, с использованием
> тезаурусов и создать аннотацию, которая ни в каком конкретном
> документе не содержится. Сложность соответственно тоже очень разная,
> от простого подсчёта и выбора наиболее частотной сущности до сложных
> алгоритмов машинного обучения с использованием лингвистического
> обеспечения.

>> Может кто знает алгоритмы поиска названий кластеров, когда на кластеры
>> разбиваются текстовые документы?
>>



-- 
С уважением,
 Михаил                          mailto:postmaster на softsearch.ru


From dsimonov на yandex-team.ru  Sun Oct 30 09:41:57 2011
From: dsimonov на yandex-team.ru (Dmitry Simonov)
Date: Sun, 30 Oct 2011 20:41:57 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <CAKb9G9h2buQbb7ozQ=3DU6Jc25NkEp3hyruAnKbhp2HZkaMbZA@mail.gmail.com>
References: <CAKb9G9gFJhBrddvXm9hBwYcX2FPoEoyZLTLTj6haPwKEEB+42g@mail.gmail.com>
	<6230E835-C5C9-4DDB-B2BF-5A4C2F5E8B0C@rambler-co.ru>
	<CAKb9G9gfcsmO2oNL2cvCED6pHL0zU+nns-VyGJLSU+ynp-tKmg@mail.gmail.com>
	<CAFtO3fk=MraZ9xSQRUmEhvXkYfQec3CHq+XGQ_5En9QiR5t9Rg@mail.gmail.com>
	<CAKb9G9h2buQbb7ozQ=3DU6Jc25NkEp3hyruAnKbhp2HZkaMbZA@mail.gmail.com>
Message-ID: <CAL9wMxUrDjuh14cvt0xjK9PF=XVVe7qFY7z8LZictTZ1HoGiAQ@mail.gmail.com>

Я Тебе ещё с @yandex-team.ru отпишусь, что LOL.

2011/10/29 Alexandr Gomoliako <zzz на zzz.org.ua>:
> On Sat, Oct 29, 2011 at 3:09 AM, Yury Pats <yu.pats на gmail.com> wrote:
>> 2011/10/29 Alexandr Gomoliako <zzz на zzz.org.ua>:
>>> On Sat, Oct 29, 2011 at 2:59 AM, Mons Anderson <mons на rambler-co.ru> wrote:
>>>> Увидел-бы такое, уволил бы сразу за некомпетентность.
>>>> Под апачом запускайте такую прелесть. Не понимаете сути асинхронных процессов - не лезьте в nginx с попыткой там что-то запрогать на перле.
>>>
>>> Вот вы сейчас проявляете полнейшую некомпетентность.
>>> Напишите, что вам не ясно, объясню.
>>
>> LOL
>
> Чего LOL? Я серьезно. А то такое заявлять, еще и с rambler-co.ru.
> Рамблеру должно быть очень стыдно.
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>

From zzz на zzz.org.ua  Sun Oct 30 10:15:27 2011
From: zzz на zzz.org.ua (Alexandr Gomoliako)
Date: Sun, 30 Oct 2011 19:15:27 +0200
Subject: [Moscow.pm]
	=?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
	=?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <CAL9wMxUrDjuh14cvt0xjK9PF=XVVe7qFY7z8LZictTZ1HoGiAQ@mail.gmail.com>
References: <CAKb9G9gFJhBrddvXm9hBwYcX2FPoEoyZLTLTj6haPwKEEB+42g@mail.gmail.com>
	<6230E835-C5C9-4DDB-B2BF-5A4C2F5E8B0C@rambler-co.ru>
	<CAKb9G9gfcsmO2oNL2cvCED6pHL0zU+nns-VyGJLSU+ynp-tKmg@mail.gmail.com>
	<CAFtO3fk=MraZ9xSQRUmEhvXkYfQec3CHq+XGQ_5En9QiR5t9Rg@mail.gmail.com>
	<CAKb9G9h2buQbb7ozQ=3DU6Jc25NkEp3hyruAnKbhp2HZkaMbZA@mail.gmail.com>
	<CAL9wMxUrDjuh14cvt0xjK9PF=XVVe7qFY7z8LZictTZ1HoGiAQ@mail.gmail.com>
Message-ID: <CAKb9G9j_dwuqQpmsY9q6ygh8f8Z+ZCNhOq=cgexBxrGWr3cCDQ@mail.gmail.com>

On Sun, Oct 30, 2011 at 6:41 PM, Dmitry Simonov <dsimonov на yandex-team.ru> wrote:
> Я Тебе ещё с @yandex-team.ru отпишусь, что LOL.

Ясно все с вами :)

From dsimonov на gmail.com  Sun Oct 30 10:38:34 2011
From: dsimonov на gmail.com (Dmitry Simonov)
Date: Sun, 30 Oct 2011 21:38:34 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <CAKb9G9j_dwuqQpmsY9q6ygh8f8Z+ZCNhOq=cgexBxrGWr3cCDQ@mail.gmail.com>
References: <CAKb9G9gFJhBrddvXm9hBwYcX2FPoEoyZLTLTj6haPwKEEB+42g@mail.gmail.com>
	<6230E835-C5C9-4DDB-B2BF-5A4C2F5E8B0C@rambler-co.ru>
	<CAKb9G9gfcsmO2oNL2cvCED6pHL0zU+nns-VyGJLSU+ynp-tKmg@mail.gmail.com>
	<CAFtO3fk=MraZ9xSQRUmEhvXkYfQec3CHq+XGQ_5En9QiR5t9Rg@mail.gmail.com>
	<CAKb9G9h2buQbb7ozQ=3DU6Jc25NkEp3hyruAnKbhp2HZkaMbZA@mail.gmail.com>
	<CAL9wMxUrDjuh14cvt0xjK9PF=XVVe7qFY7z8LZictTZ1HoGiAQ@mail.gmail.com>
	<CAKb9G9j_dwuqQpmsY9q6ygh8f8Z+ZCNhOq=cgexBxrGWr3cCDQ@mail.gmail.com>
Message-ID: <CAL9wMxU15_ArY+SJa57Vf1bdy2f=o-H6YHmt27w9eBkaLa6Xzw@mail.gmail.com>

Ты не переживай. У меня один экс-коллега встроил в большой нагруженный
сервис в обёртку к контроллерам при вызове всех (!) экшнов LWP запрос
к стороннему сервису. На мой вопрос честно ответил: "ну а чем
LWP-запрос отличается от запроса к БД? Он такой же блокирующий :)"

---
Dmitriy V. Simonov,
Perl & Python programmer



2011/10/30 Alexandr Gomoliako <zzz на zzz.org.ua>:
> On Sun, Oct 30, 2011 at 6:41 PM, Dmitry Simonov <dsimonov на yandex-team.ru> wrote:
>> Я Тебе ещё с @yandex-team.ru отпишусь, что LOL.
>
> Ясно все с вами :)
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>

From zzz на zzz.org.ua  Sun Oct 30 11:04:43 2011
From: zzz на zzz.org.ua (Alexandr Gomoliako)
Date: Sun, 30 Oct 2011 20:04:43 +0200
Subject: [Moscow.pm]
	=?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
	=?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <CAL9wMxU15_ArY+SJa57Vf1bdy2f=o-H6YHmt27w9eBkaLa6Xzw@mail.gmail.com>
References: <CAKb9G9gFJhBrddvXm9hBwYcX2FPoEoyZLTLTj6haPwKEEB+42g@mail.gmail.com>
	<6230E835-C5C9-4DDB-B2BF-5A4C2F5E8B0C@rambler-co.ru>
	<CAKb9G9gfcsmO2oNL2cvCED6pHL0zU+nns-VyGJLSU+ynp-tKmg@mail.gmail.com>
	<CAFtO3fk=MraZ9xSQRUmEhvXkYfQec3CHq+XGQ_5En9QiR5t9Rg@mail.gmail.com>
	<CAKb9G9h2buQbb7ozQ=3DU6Jc25NkEp3hyruAnKbhp2HZkaMbZA@mail.gmail.com>
	<CAL9wMxUrDjuh14cvt0xjK9PF=XVVe7qFY7z8LZictTZ1HoGiAQ@mail.gmail.com>
	<CAKb9G9j_dwuqQpmsY9q6ygh8f8Z+ZCNhOq=cgexBxrGWr3cCDQ@mail.gmail.com>
	<CAL9wMxU15_ArY+SJa57Vf1bdy2f=o-H6YHmt27w9eBkaLa6Xzw@mail.gmail.com>
Message-ID: <CAKb9G9hNUB2Ute7bxP-Bd0tDRb0Fnf-_ew=9mSnbX_mgUwzHCA@mail.gmail.com>

On Sun, Oct 30, 2011 at 7:38 PM, Dmitry Simonov <dsimonov на gmail.com> wrote:
> Ты не переживай. У меня один экс-коллега встроил в большой нагруженный
> сервис в обёртку к контроллерам при вызове всех (!) экшнов LWP запрос
> к стороннему сервису. На мой вопрос честно ответил: "ну а чем
> LWP-запрос отличается от запроса к БД? Он такой же блокирующий :)"

Т.е. вы не осознаете, что какой-то префорк сервер, типа apache 1.x,
является частным случаем неблокирующего с одним соединением
на воркер и кучей воркеров?

Даже более того, внутри любого вменяемого блокирующего сервера
без select()'а вообще никак. Т.е. они блокируются на select(), а не на recv().
Ну или на poll/epoll/kqueue etc.

В общем укзаывайте реальные причины, почему вы думаете, что так
"плохо" или хуже, чем что-то там другое.

From dsimonov на gmail.com  Sun Oct 30 11:20:00 2011
From: dsimonov на gmail.com (Dmitry Simonov)
Date: Sun, 30 Oct 2011 22:20:00 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <CAKb9G9hNUB2Ute7bxP-Bd0tDRb0Fnf-_ew=9mSnbX_mgUwzHCA@mail.gmail.com>
References: <CAKb9G9gFJhBrddvXm9hBwYcX2FPoEoyZLTLTj6haPwKEEB+42g@mail.gmail.com>
	<6230E835-C5C9-4DDB-B2BF-5A4C2F5E8B0C@rambler-co.ru>
	<CAKb9G9gfcsmO2oNL2cvCED6pHL0zU+nns-VyGJLSU+ynp-tKmg@mail.gmail.com>
	<CAFtO3fk=MraZ9xSQRUmEhvXkYfQec3CHq+XGQ_5En9QiR5t9Rg@mail.gmail.com>
	<CAKb9G9h2buQbb7ozQ=3DU6Jc25NkEp3hyruAnKbhp2HZkaMbZA@mail.gmail.com>
	<CAL9wMxUrDjuh14cvt0xjK9PF=XVVe7qFY7z8LZictTZ1HoGiAQ@mail.gmail.com>
	<CAKb9G9j_dwuqQpmsY9q6ygh8f8Z+ZCNhOq=cgexBxrGWr3cCDQ@mail.gmail.com>
	<CAL9wMxU15_ArY+SJa57Vf1bdy2f=o-H6YHmt27w9eBkaLa6Xzw@mail.gmail.com>
	<CAKb9G9hNUB2Ute7bxP-Bd0tDRb0Fnf-_ew=9mSnbX_mgUwzHCA@mail.gmail.com>
Message-ID: <CAL9wMxWQw3g7cQdih0-_zH=__=CVtkprwROQmrpV8owa7Uh7ag@mail.gmail.com>

Саш! Ты со мной не спорь, - я тот ещё тролль и все это здесь подтвердят.
А случай привёл, чтобы было понятно, - косяки я видел и много и
разных. Как и сам совершал.

Что касается Монса и Твоих наездов на него по поводу разработки на
перле в nginx. Это примерно также, как спорить с Сысоевым. Потому и
LOL.

Тем закрыта. Точка.

---
Dmitriy V. Simonov,
Perl & Python programmer



2011/10/30 Alexandr Gomoliako <zzz на zzz.org.ua>:
> On Sun, Oct 30, 2011 at 7:38 PM, Dmitry Simonov <dsimonov на gmail.com> wrote:
>> Ты не переживай. У меня один экс-коллега встроил в большой нагруженный
>> сервис в обёртку к контроллерам при вызове всех (!) экшнов LWP запрос
>> к стороннему сервису. На мой вопрос честно ответил: "ну а чем
>> LWP-запрос отличается от запроса к БД? Он такой же блокирующий :)"
>
> Т.е. вы не осознаете, что какой-то префорк сервер, типа apache 1.x,
> является частным случаем неблокирующего с одним соединением
> на воркер и кучей воркеров?
>
> Даже более того, внутри любого вменяемого блокирующего сервера
> без select()'а вообще никак. Т.е. они блокируются на select(), а не на recv().
> Ну или на poll/epoll/kqueue etc.
>
> В общем укзаывайте реальные причины, почему вы думаете, что так
> "плохо" или хуже, чем что-то там другое.
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>

From dsimonov на gmail.com  Sun Oct 30 11:23:36 2011
From: dsimonov на gmail.com (Dmitry Simonov)
Date: Sun, 30 Oct 2011 22:23:36 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <CAL9wMxWQw3g7cQdih0-_zH=__=CVtkprwROQmrpV8owa7Uh7ag@mail.gmail.com>
References: <CAKb9G9gFJhBrddvXm9hBwYcX2FPoEoyZLTLTj6haPwKEEB+42g@mail.gmail.com>
	<6230E835-C5C9-4DDB-B2BF-5A4C2F5E8B0C@rambler-co.ru>
	<CAKb9G9gfcsmO2oNL2cvCED6pHL0zU+nns-VyGJLSU+ynp-tKmg@mail.gmail.com>
	<CAFtO3fk=MraZ9xSQRUmEhvXkYfQec3CHq+XGQ_5En9QiR5t9Rg@mail.gmail.com>
	<CAKb9G9h2buQbb7ozQ=3DU6Jc25NkEp3hyruAnKbhp2HZkaMbZA@mail.gmail.com>
	<CAL9wMxUrDjuh14cvt0xjK9PF=XVVe7qFY7z8LZictTZ1HoGiAQ@mail.gmail.com>
	<CAKb9G9j_dwuqQpmsY9q6ygh8f8Z+ZCNhOq=cgexBxrGWr3cCDQ@mail.gmail.com>
	<CAL9wMxU15_ArY+SJa57Vf1bdy2f=o-H6YHmt27w9eBkaLa6Xzw@mail.gmail.com>
	<CAKb9G9hNUB2Ute7bxP-Bd0tDRb0Fnf-_ew=9mSnbX_mgUwzHCA@mail.gmail.com>
	<CAL9wMxWQw3g7cQdih0-_zH=__=CVtkprwROQmrpV8owa7Uh7ag@mail.gmail.com>
Message-ID: <CAL9wMxWZH=o3OtLrL=+BTOzH8HVu8XbuPGCJ72rsN8Tmmf9o4Q@mail.gmail.com>

Забыл сказать. Пришли в личку своё резюме, - уж очень активно сыпешь
баззвордами. А мне тут разработчики нужны :)

---
Dmitriy V. Simonov,
Perl & Python programmer



2011/10/30 Dmitry Simonov <dsimonov на gmail.com>:
> Саш! Ты со мной не спорь, - я тот ещё тролль и все это здесь подтвердят.
> А случай привёл, чтобы было понятно, - косяки я видел и много и
> разных. Как и сам совершал.
>
> Что касается Монса и Твоих наездов на него по поводу разработки на
> перле в nginx. Это примерно также, как спорить с Сысоевым. Потому и
> LOL.
>
> Тем закрыта. Точка.
>
> ---
> Dmitriy V. Simonov,
> Perl & Python programmer
>
>
>
> 2011/10/30 Alexandr Gomoliako <zzz на zzz.org.ua>:
>> On Sun, Oct 30, 2011 at 7:38 PM, Dmitry Simonov <dsimonov на gmail.com> wrote:
>>> Ты не переживай. У меня один экс-коллега встроил в большой нагруженный
>>> сервис в обёртку к контроллерам при вызове всех (!) экшнов LWP запрос
>>> к стороннему сервису. На мой вопрос честно ответил: "ну а чем
>>> LWP-запрос отличается от запроса к БД? Он такой же блокирующий :)"
>>
>> Т.е. вы не осознаете, что какой-то префорк сервер, типа apache 1.x,
>> является частным случаем неблокирующего с одним соединением
>> на воркер и кучей воркеров?
>>
>> Даже более того, внутри любого вменяемого блокирующего сервера
>> без select()'а вообще никак. Т.е. они блокируются на select(), а не на recv().
>> Ну или на poll/epoll/kqueue etc.
>>
>> В общем укзаывайте реальные причины, почему вы думаете, что так
>> "плохо" или хуже, чем что-то там другое.
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>
>

From zzz на zzz.org.ua  Sun Oct 30 11:36:37 2011
From: zzz на zzz.org.ua (Alexandr Gomoliako)
Date: Sun, 30 Oct 2011 20:36:37 +0200
Subject: [Moscow.pm]
	=?koi8-r?b?8sHazdnbzMXOydEgzsEg1MXN1SBPUk0gySDXz8/C?=
	=?koi8-r?b?3cUg0sHCz9TZINMg4uQ=?=
In-Reply-To: <CAL9wMxWQw3g7cQdih0-_zH=__=CVtkprwROQmrpV8owa7Uh7ag@mail.gmail.com>
References: <CAKb9G9gFJhBrddvXm9hBwYcX2FPoEoyZLTLTj6haPwKEEB+42g@mail.gmail.com>
	<6230E835-C5C9-4DDB-B2BF-5A4C2F5E8B0C@rambler-co.ru>
	<CAKb9G9gfcsmO2oNL2cvCED6pHL0zU+nns-VyGJLSU+ynp-tKmg@mail.gmail.com>
	<CAFtO3fk=MraZ9xSQRUmEhvXkYfQec3CHq+XGQ_5En9QiR5t9Rg@mail.gmail.com>
	<CAKb9G9h2buQbb7ozQ=3DU6Jc25NkEp3hyruAnKbhp2HZkaMbZA@mail.gmail.com>
	<CAL9wMxUrDjuh14cvt0xjK9PF=XVVe7qFY7z8LZictTZ1HoGiAQ@mail.gmail.com>
	<CAKb9G9j_dwuqQpmsY9q6ygh8f8Z+ZCNhOq=cgexBxrGWr3cCDQ@mail.gmail.com>
	<CAL9wMxU15_ArY+SJa57Vf1bdy2f=o-H6YHmt27w9eBkaLa6Xzw@mail.gmail.com>
	<CAKb9G9hNUB2Ute7bxP-Bd0tDRb0Fnf-_ew=9mSnbX_mgUwzHCA@mail.gmail.com>
	<CAL9wMxWQw3g7cQdih0-_zH=__=CVtkprwROQmrpV8owa7Uh7ag@mail.gmail.com>
Message-ID: <CAKb9G9hCOQWVygbLSoen61Rpm0_ej+oFCxqbF6NBeivfgV-6UA@mail.gmail.com>

On Sun, Oct 30, 2011 at 8:20 PM, Dmitry Simonov <dsimonov на gmail.com> wrote:
> Что касается Монса и Твоих наездов на него по поводу разработки на
> перле в nginx. Это примерно также, как спорить с Сысоевым. Потому и
> LOL.

Да? А мне кажется, что он только начинает и суть пока до конца не понимает.

И вообще, я сейчас единственный, кто занимается встроенным перлом в nginx,
не видел в nginx-devel монсов всяких. И по-моему кроме Игоря, там вообще
никого перл модуль не волнует.

From dsimonov на gmail.com  Sun Oct 30 11:45:25 2011
From: dsimonov на gmail.com (Dmitry Simonov)
Date: Sun, 30 Oct 2011 22:45:25 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <CAKb9G9hCOQWVygbLSoen61Rpm0_ej+oFCxqbF6NBeivfgV-6UA@mail.gmail.com>
References: <CAKb9G9gFJhBrddvXm9hBwYcX2FPoEoyZLTLTj6haPwKEEB+42g@mail.gmail.com>
	<6230E835-C5C9-4DDB-B2BF-5A4C2F5E8B0C@rambler-co.ru>
	<CAKb9G9gfcsmO2oNL2cvCED6pHL0zU+nns-VyGJLSU+ynp-tKmg@mail.gmail.com>
	<CAFtO3fk=MraZ9xSQRUmEhvXkYfQec3CHq+XGQ_5En9QiR5t9Rg@mail.gmail.com>
	<CAKb9G9h2buQbb7ozQ=3DU6Jc25NkEp3hyruAnKbhp2HZkaMbZA@mail.gmail.com>
	<CAL9wMxUrDjuh14cvt0xjK9PF=XVVe7qFY7z8LZictTZ1HoGiAQ@mail.gmail.com>
	<CAKb9G9j_dwuqQpmsY9q6ygh8f8Z+ZCNhOq=cgexBxrGWr3cCDQ@mail.gmail.com>
	<CAL9wMxU15_ArY+SJa57Vf1bdy2f=o-H6YHmt27w9eBkaLa6Xzw@mail.gmail.com>
	<CAKb9G9hNUB2Ute7bxP-Bd0tDRb0Fnf-_ew=9mSnbX_mgUwzHCA@mail.gmail.com>
	<CAL9wMxWQw3g7cQdih0-_zH=__=CVtkprwROQmrpV8owa7Uh7ag@mail.gmail.com>
	<CAKb9G9hCOQWVygbLSoen61Rpm0_ej+oFCxqbF6NBeivfgV-6UA@mail.gmail.com>
Message-ID: <CAL9wMxUzqGKmb3MVUsSOrVTQi=uW3t9J0sSd+Z5qCyFUrTjiEw@mail.gmail.com>

(удобно усаживается в кресле запасший попкорном)

---
Dmitriy V. Simonov,
Perl & Python programmer



2011/10/30 Alexandr Gomoliako <zzz на zzz.org.ua>:
> On Sun, Oct 30, 2011 at 8:20 PM, Dmitry Simonov <dsimonov на gmail.com> wrote:
>> Что касается Монса и Твоих наездов на него по поводу разработки на
>> перле в nginx. Это примерно также, как спорить с Сысоевым. Потому и()
>> LOL.
>
> Да? А мне кажется, что он только начинает и суть пока до конца не понимает.
>
> И вообще, я сейчас единственный, кто занимается встроенным перлом в nginx,
> не видел в nginx-devel монсов всяких. И по-моему кроме Игоря, там вообще
> никого перл модуль не волнует.
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>

From grigory.sapunov на gmail.com  Sun Oct 30 12:32:46 2011
From: grigory.sapunov на gmail.com (Grigory V.Sapunov)
Date: Sun, 30 Oct 2011 23:32:46 +0400
Subject: [Moscow.pm] =?koi8-r?b?6c3FzsEgy8zB09TF0s/XLg==?=
In-Reply-To: <1015101794.20111030204039@softsearch.ru>
References: <1367200608.20111029221805@softsearch.ru>
	<CAOZ5q3Nsb6U2CSjXUmpNNveCU9Wy6WpzhCxEnrOp_4dZEt_Sig@mail.gmail.com>
	<1015101794.20111030204039@softsearch.ru>
Message-ID: <CAOZ5q3NvxBPBcZQ4PWtJLuofWXnkgydrbDWxCVvXhykTzB=wfw@mail.gmail.com>

Если совсем введение интересует, можно начать с книги Мэннинга, Шютце и
Рагхавана (http://www-nlp.stanford.edu/IR-book/), главы про кластеризацию,
статья в википедии во многом по ней построена:
http://en.wikipedia.org/wiki/Cluster_labeling

Введение в аннотирование есть у Мартина с Журафским в 23-й главе:
http://www.amazon.com/speech-language-processing-daniel-jurafsky/dp/0131873210

Если нужно более глубоко, то скорее придётся по публикациям в тематических
журналах и трудах конференций копать. Готовых книг, посвящённых именно этой
проблеме, мне в руки не попадалось. Хотя у Springer что-то было...

2011/10/30 Михаил Монашёв <postmaster на softsearch.ru>

> Здравствуйте, Grigory.
>
> Я хотел теорию почитать.
>
> > А какая конкретно задача? Этому целая область посвящена -- Multiple
> > Document Summarization.
>
> > Где-то для этого достаточно выбрать заголовок одного из документов,
> > где-то достаточно наиболее представительного тэга или именной группы,
> > а где-то нужно ещё и сделать обобщение, например, с использованием
> > тезаурусов и создать аннотацию, которая ни в каком конкретном
> > документе не содержится. Сложность соответственно тоже очень разная,
> > от простого подсчёта и выбора наиболее частотной сущности до сложных
> > алгоритмов машинного обучения с использованием лингвистического
> > обеспечения.
>
> >> Может кто знает алгоритмы поиска названий кластеров, когда на кластеры
> >> разбиваются текстовые документы?
> >>
>
>
>
> --
> С уважением,
>  Михаил                          mailto:postmaster на softsearch.ru
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111030/5b1f6a24/attachment.html>

From mons на rambler-co.ru  Sun Oct 30 14:06:51 2011
From: mons на rambler-co.ru (Mons Anderson)
Date: Mon, 31 Oct 2011 00:06:51 +0300
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <CAGOcgF0wNg2QeY5aOoD8XmtbXQACh4NH9H3k23LNQtfytu2WdQ@mail.gmail.com>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
	<20111028115949.GZ24610@rabbit.us>
	<22C06B3C-76F7-4DC3-AAD1-7C426D734527@rambler-co.ru>
	<D86EF836-B347-4969-8D17-EF604DDF0EF9@aaanet.ru>
	<5E887940-C8D2-4B90-A47A-C5E1AFAAAFF6@rambler-co.ru>
	<CAGOcgF0wNg2QeY5aOoD8XmtbXQACh4NH9H3k23LNQtfytu2WdQ@mail.gmail.com>
Message-ID: <1E6DA01D-F46C-49F5-BD4A-1EF0591BA285@rambler-co.ru>

Все сразу это может быть ~ 14M записей.
давайте все-таки конкретные примеры решений. "через подзапрос" или "через объединение" это не ответ.

On 29.10.2011, at 17:23, Akzhan Abdulin wrote:

> Ну это тривиально. Например, через подзапрос. А можно через объединение. Можно все вместе сразу вытащить.
> 
> 29 октября 2011 г. 15:27 пользователь Mons Anderson <mons на rambler-co.ru> написал:
> Задача:
> 
> 1. Есть некий сложный resultset (joins, filters, order by).
> 2. Есть id одной строки, который заведомо входит в этот resultset.
> нужно выбрать еще 2 строки: ту, которая идет перед этим id и после него.
> 
> Пример псевдозапроса, генерируемого resultset'ом:
> select * from photos join users join likes where photo.access > 2 and photo.album = 10 order by likes desc, photo.id asc
> 
> Попробуйте ее решить.
> В понедельник кину более детальный пример с решением и объяснением.
> 
> On 29.10.2011, at 12:12, Евгений Торопов wrote:
> 
> > Патч интересно было бы посмотреть, да, а вот про пред/след - че-то не понял я, почему via DBIC можно модифицировать запрос, а via DBI / sql-генератор нет
> >
> > On Oct 29, 2011, at 3:52 AM, Mons Anderson wrote:
> >
> >> Кстати мы с vovkasm патчили Class::Accessor::Grouped по аналогии с Class::XSaccessor.
> >> Ускоряло работу DBIC в несколько раз.
> >> так что в итоге производительность вполне приближалась к DBI.
> >>
> >> Кстати еще в тему DBIC:
> >> у нас на проекте есть десятки различных выборок. некоторые делаются из одной таблицы с разными join'ами и разными условиями, некоторые из другой, но к ней join'ится первая таблица.
> >> так вот нам понадобилось сделать запрос, который выбрал бы предыдущий и следующий элемент из текущей выборки (resultset'a), относительно текущего.
> >>
> >> используя DBIC эта задача была вполне решаема, т.к. весь запрос представлен в виде объекта и параметров и мы можем полностью проанализировать из чего он состоит и модифицировать его.
> >> В случае использования raw DBI на N выборок пришлось бы писать 2N запросов на предыдущий/следующий элемент. И при модификации одного из запросов менять соответственно другие 2.
> >>
> >> Так что при том, что DBIC это оверхед - это порой вполне оправданый оверхед.
> >> Хотя я не спорю с тем, что на каких-то highload проектах мы отказыаваемся от DBIC в пользу чистого DBI.
> >> Хотя на стадии прототипизации DBIC вполне приемлем т.к. сильно упрощает разработку.
> >>
> >> On 28.10.2011, at 15:59, Peter Rabbitson wrote:
> >>
> >>> On Fri, Oct 28, 2011 at 01:51:00PM +0200, Andrei wrote:
> >>>> 28 октября 2011 г. 13:35 пользователь Евгений Торопов <jt на aaanet.ru>написал:
> >>>>
> >>>>> On Oct 28, 2011, at 3:11 PM, Andrei wrote:
> >>>>>
> >>>>> 28 октября 2011 г. 13:08 пользователь Ivan Petrov <i.petro.77.00 на gmail.com
> >>>>>> написал:
> >>>>>
> >>>>>>> Твой аргумент какой то дикий - разница м/у DBIC и писать ручками SQL
> >>>>>>> подобна той между Perl и писать ручками assembler. Тебе Perl часом не
> >>>>>>> мешает?
> >>>>>>
> >>>>>> неуместное сравнение.
> >>>>>>
> >>>>>> говорить о DBIC vs писать SQL ручками вообще нельзя. ибо DBIC умеет
> >>>>>> составлять только самые простые запросы.
> >>>>>>
> >>>>>> а на реальных задачах получаются либо извращения (вроде специальные
> >>>>>> VIEW'ы дабы DBIC в них смотрел и не пытался самостоятельничать), либо
> >>>>>> те же запросы ручками
> >>>>>>
> >>>>>
> >>>>>
> >>>>> DBIC автоматизиреут наиболее частые простые задачи.
> >>>>>
> >>>>>
> >>>>> Наиболее частые простые задачи автоматизируются примитивнейшими
> >>>>> sql-генераторами и не стоят того, чтоб иметь пиздец какой оверхед (
> >>>>> http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/03/benchmarking-dbixclass-vs-plain-dbi-on-hailo.html ).
> >>>>> Если бенчмарки по ссылке устарели - покажите новые.
> >>>>>
> >>>>>
> >>>> Вы бы Айвара до конца читали. А там написано:
> >>>>
> >>>
> >>> А зачем мне его читать, когда я с ним лично говорил пока он замеры проводил :)
> >>> Я ктому ответил что "Да, у DBIC узких мест полно, о них знаем, над ними
> >>> работаем и если надо прямо чтоб сегодня быстро - надо так (->cursor)"
> >>>
> >>> --
> >>> Moscow.pm mailing list
> >>> moscow-pm на pm.org | http://moscow.pm.org
> >>
> >> --
> >> Moscow.pm mailing list
> >> moscow-pm на pm.org | http://moscow.pm.org
> >
> > --
> > Moscow.pm mailing list
> > moscow-pm на pm.org | http://moscow.pm.org
> 
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
> 
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111031/27095748/attachment-0001.html>

From akzhan.abdulin на gmail.com  Sun Oct 30 14:20:17 2011
From: akzhan.abdulin на gmail.com (Akzhan Abdulin)
Date: Mon, 31 Oct 2011 01:20:17 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <1E6DA01D-F46C-49F5-BD4A-1EF0591BA285@rambler-co.ru>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
	<20111028115949.GZ24610@rabbit.us>
	<22C06B3C-76F7-4DC3-AAD1-7C426D734527@rambler-co.ru>
	<D86EF836-B347-4969-8D17-EF604DDF0EF9@aaanet.ru>
	<5E887940-C8D2-4B90-A47A-C5E1AFAAAFF6@rambler-co.ru>
	<CAGOcgF0wNg2QeY5aOoD8XmtbXQACh4NH9H3k23LNQtfytu2WdQ@mail.gmail.com>
	<1E6DA01D-F46C-49F5-BD4A-1EF0591BA285@rambler-co.ru>
Message-ID: <CAGOcgF1Qv=eXnTnp1VT30B6CFynRr-Zby21DnG6QD_sXhe0k1g@mail.gmail.com>

простой случай - упорядоченность по одному полю. навскидку:

например, если поддерживается ANSI SQL в части подзапросов с условиями:
select * from #{table} where #{filters} and #{ordered_field} < (select
#{ordered_field} from #{table} where id = #{id}) order by #{order} limit 1;

при необходимости переписывается в объединение.
select tf.* from #{table} tid inner join #{table} tf on tf.#{ordered_field}
< tid.#{ordered_field} where tid.id = #{id} and #{tf.filters} order by
#{tf.order} limit 1;


31 октября 2011 г. 1:06 пользователь Mons Anderson <mons на rambler-co.ru>написал:

> Все сразу это может быть ~ 14M записей.
> давайте все-таки конкретные примеры решений. "через подзапрос" или "через
> объединение" это не ответ.
>
> On 29.10.2011, at 17:23, Akzhan Abdulin wrote:
>
> Ну это тривиально. Например, через подзапрос. А можно через объединение.
> Можно все вместе сразу вытащить.
>
> 29 октября 2011 г. 15:27 пользователь Mons Anderson <mons на rambler-co.ru>написал:
>
>> Задача:
>>
>> 1. Есть некий сложный resultset (joins, filters, order by).
>> 2. Есть id одной строки, который заведомо входит в этот resultset.
>> нужно выбрать еще 2 строки: ту, которая идет перед этим id и после него.
>>
>> Пример псевдозапроса, генерируемого resultset'ом:
>> select * from photos join users join likes where photo.access > 2 and
>> photo.album = 10 order by likes desc, photo.id asc
>>
>> Попробуйте ее решить.
>> В понедельник кину более детальный пример с решением и объяснением.
>>
>> On 29.10.2011, at 12:12, Евгений Торопов wrote:
>>
>> > Патч интересно было бы посмотреть, да, а вот про пред/след - че-то не
>> понял я, почему via DBIC можно модифицировать запрос, а via DBI /
>> sql-генератор нет
>> >
>> > On Oct 29, 2011, at 3:52 AM, Mons Anderson wrote:
>> >
>> >> Кстати мы с vovkasm патчили Class::Accessor::Grouped по аналогии с
>> Class::XSaccessor.
>> >> Ускоряло работу DBIC в несколько раз.
>> >> так что в итоге производительность вполне приближалась к DBI.
>> >>
>> >> Кстати еще в тему DBIC:
>> >> у нас на проекте есть десятки различных выборок. некоторые делаются из
>> одной таблицы с разными join'ами и разными условиями, некоторые из другой,
>> но к ней join'ится первая таблица.
>> >> так вот нам понадобилось сделать запрос, который выбрал бы предыдущий
>> и следующий элемент из текущей выборки (resultset'a), относительно текущего.
>> >>
>> >> используя DBIC эта задача была вполне решаема, т.к. весь запрос
>> представлен в виде объекта и параметров и мы можем полностью
>> проанализировать из чего он состоит и модифицировать его.
>> >> В случае использования raw DBI на N выборок пришлось бы писать 2N
>> запросов на предыдущий/следующий элемент. И при модификации одного из
>> запросов менять соответственно другие 2.
>> >>
>> >> Так что при том, что DBIC это оверхед - это порой вполне оправданый
>> оверхед.
>> >> Хотя я не спорю с тем, что на каких-то highload проектах мы
>> отказыаваемся от DBIC в пользу чистого DBI.
>> >> Хотя на стадии прототипизации DBIC вполне приемлем т.к. сильно
>> упрощает разработку.
>> >>
>> >> On 28.10.2011, at 15:59, Peter Rabbitson wrote:
>> >>
>> >>> On Fri, Oct 28, 2011 at 01:51:00PM +0200, Andrei wrote:
>> >>>> 28 октября 2011 г. 13:35 пользователь Евгений Торопов <jt на aaanet.ru
>> >написал:
>> >>>>
>> >>>>> On Oct 28, 2011, at 3:11 PM, Andrei wrote:
>> >>>>>
>> >>>>> 28 октября 2011 г. 13:08 пользователь Ivan Petrov <
>> i.petro.77.00 на gmail.com
>> >>>>>> написал:
>> >>>>>
>> >>>>>>> Твой аргумент какой то дикий - разница м/у DBIC и писать ручками
>> SQL
>> >>>>>>> подобна той между Perl и писать ручками assembler. Тебе Perl
>> часом не
>> >>>>>>> мешает?
>> >>>>>>
>> >>>>>> неуместное сравнение.
>> >>>>>>
>> >>>>>> говорить о DBIC vs писать SQL ручками вообще нельзя. ибо DBIC умеет
>> >>>>>> составлять только самые простые запросы.
>> >>>>>>
>> >>>>>> а на реальных задачах получаются либо извращения (вроде специальные
>> >>>>>> VIEW'ы дабы DBIC в них смотрел и не пытался самостоятельничать),
>> либо
>> >>>>>> те же запросы ручками
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>> DBIC автоматизиреут наиболее частые простые задачи.
>> >>>>>
>> >>>>>
>> >>>>> Наиболее частые простые задачи автоматизируются примитивнейшими
>> >>>>> sql-генераторами и не стоят того, чтоб иметь пиздец какой оверхед (
>> >>>>>
>> http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/03/benchmarking-dbixclass-vs-plain-dbi-on-hailo.html).
>> >>>>> Если бенчмарки по ссылке устарели - покажите новые.
>> >>>>>
>> >>>>>
>> >>>> Вы бы Айвара до конца читали. А там написано:
>> >>>>
>> >>>
>> >>> А зачем мне его читать, когда я с ним лично говорил пока он замеры
>> проводил :)
>> >>> Я ктому ответил что "Да, у DBIC узких мест полно, о них знаем, над
>> ними
>> >>> работаем и если надо прямо чтоб сегодня быстро - надо так (->cursor)"
>> >>>
>> >>> --
>> >>> Moscow.pm mailing list
>> >>> moscow-pm на pm.org | http://moscow.pm.org
>> >>
>> >> --
>> >> Moscow.pm mailing list
>> >> moscow-pm на pm.org | http://moscow.pm.org
>> >
>> > --
>> > Moscow.pm mailing list
>> > moscow-pm на pm.org | http://moscow.pm.org
>>
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111031/e51b2a17/attachment.html>

From akzhan.abdulin на gmail.com  Sun Oct 30 14:26:59 2011
From: akzhan.abdulin на gmail.com (Akzhan Abdulin)
Date: Mon, 31 Oct 2011 01:26:59 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <CAKb9G9hCOQWVygbLSoen61Rpm0_ej+oFCxqbF6NBeivfgV-6UA@mail.gmail.com>
References: <CAKb9G9gFJhBrddvXm9hBwYcX2FPoEoyZLTLTj6haPwKEEB+42g@mail.gmail.com>
	<6230E835-C5C9-4DDB-B2BF-5A4C2F5E8B0C@rambler-co.ru>
	<CAKb9G9gfcsmO2oNL2cvCED6pHL0zU+nns-VyGJLSU+ynp-tKmg@mail.gmail.com>
	<CAFtO3fk=MraZ9xSQRUmEhvXkYfQec3CHq+XGQ_5En9QiR5t9Rg@mail.gmail.com>
	<CAKb9G9h2buQbb7ozQ=3DU6Jc25NkEp3hyruAnKbhp2HZkaMbZA@mail.gmail.com>
	<CAL9wMxUrDjuh14cvt0xjK9PF=XVVe7qFY7z8LZictTZ1HoGiAQ@mail.gmail.com>
	<CAKb9G9j_dwuqQpmsY9q6ygh8f8Z+ZCNhOq=cgexBxrGWr3cCDQ@mail.gmail.com>
	<CAL9wMxU15_ArY+SJa57Vf1bdy2f=o-H6YHmt27w9eBkaLa6Xzw@mail.gmail.com>
	<CAKb9G9hNUB2Ute7bxP-Bd0tDRb0Fnf-_ew=9mSnbX_mgUwzHCA@mail.gmail.com>
	<CAL9wMxWQw3g7cQdih0-_zH=__=CVtkprwROQmrpV8owa7Uh7ag@mail.gmail.com>
	<CAKb9G9hCOQWVygbLSoen61Rpm0_ej+oFCxqbF6NBeivfgV-6UA@mail.gmail.com>
Message-ID: <CAGOcgF3w=9C180Z0iqAPTruCb6NH8oa+A5VPA=Er6tM2ta2CRA@mail.gmail.com>

Perl в nginx - не пришей кобыле хвост. полезен только для какой-то
встроенной логики.
Кстати, недавно модуль lua под nginx вышел - из той же оперы. как и v8.

Если делаете с его помощью что-то большее, - вы сами себе злобный буратино.

Причина - устройство событийной машины, которая лежит в основе архитектуры
nginx.

30 октября 2011 г. 22:36 пользователь Alexandr Gomoliako
<zzz на zzz.org.ua>написал:

> On Sun, Oct 30, 2011 at 8:20 PM, Dmitry Simonov <dsimonov на gmail.com>
> wrote:
> > Что касается Монса и Твоих наездов на него по поводу разработки на
> > перле в nginx. Это примерно также, как спорить с Сысоевым. Потому и
> > LOL.
>
> Да? А мне кажется, что он только начинает и суть пока до конца не понимает.
>
> И вообще, я сейчас единственный, кто занимается встроенным перлом в nginx,
> не видел в nginx-devel монсов всяких. И по-моему кроме Игоря, там вообще
> никого перл модуль не волнует.
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111031/4ba42052/attachment-0001.html>

From denis.fedoseev на gmail.com  Sun Oct 30 14:32:54 2011
From: denis.fedoseev на gmail.com (Denis Fedoseev)
Date: Mon, 31 Oct 2011 01:32:54 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
 =?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGBINCR?=
 =?utf-8?b?0JQ=?=
In-Reply-To: <CAGOcgF3w=9C180Z0iqAPTruCb6NH8oa+A5VPA=Er6tM2ta2CRA@mail.gmail.com>
References: <CAKb9G9gFJhBrddvXm9hBwYcX2FPoEoyZLTLTj6haPwKEEB+42g@mail.gmail.com>
	<6230E835-C5C9-4DDB-B2BF-5A4C2F5E8B0C@rambler-co.ru>
	<CAKb9G9gfcsmO2oNL2cvCED6pHL0zU+nns-VyGJLSU+ynp-tKmg@mail.gmail.com>
	<CAFtO3fk=MraZ9xSQRUmEhvXkYfQec3CHq+XGQ_5En9QiR5t9Rg@mail.gmail.com>
	<CAKb9G9h2buQbb7ozQ=3DU6Jc25NkEp3hyruAnKbhp2HZkaMbZA@mail.gmail.com>
	<CAL9wMxUrDjuh14cvt0xjK9PF=XVVe7qFY7z8LZictTZ1HoGiAQ@mail.gmail.com>
	<CAKb9G9j_dwuqQpmsY9q6ygh8f8Z+ZCNhOq=cgexBxrGWr3cCDQ@mail.gmail.com>
	<CAL9wMxU15_ArY+SJa57Vf1bdy2f=o-H6YHmt27w9eBkaLa6Xzw@mail.gmail.com>
	<CAKb9G9hNUB2Ute7bxP-Bd0tDRb0Fnf-_ew=9mSnbX_mgUwzHCA@mail.gmail.com>
	<CAL9wMxWQw3g7cQdih0-_zH=__=CVtkprwROQmrpV8owa7Uh7ag@mail.gmail.com>
	<CAKb9G9hCOQWVygbLSoen61Rpm0_ej+oFCxqbF6NBeivfgV-6UA@mail.gmail.com>
	<CAGOcgF3w=9C180Z0iqAPTruCb6NH8oa+A5VPA=Er6tM2ta2CRA@mail.gmail.com>
Message-ID: <1979D6B0-8364-4C47-BC75-0495DDC21223@gmail.com>

Ну в теории он может быть полезен для всяких шалобушек типа "+1" и прочей фигни, для которой сейчас используют ноду. Но на практике надо тестить что у этой конструкции будет с производительностью.


On Oct 31, 2011, at 1:26 AM, Akzhan Abdulin wrote:

> Perl в nginx - не пришей кобыле хвост. полезен только для какой-то встроенной логики.
> Кстати, недавно модуль lua под nginx вышел - из той же оперы. как и v8.
> 
> Если делаете с его помощью что-то большее, - вы сами себе злобный буратино.
> 
> Причина - устройство событийной машины, которая лежит в основе архитектуры nginx.
> 
> 30 октября 2011 г. 22:36 пользователь Alexandr Gomoliako <zzz на zzz.org.ua> написал:
> On Sun, Oct 30, 2011 at 8:20 PM, Dmitry Simonov <dsimonov на gmail.com> wrote:
> > Что касается Монса и Твоих наездов на него по поводу разработки на
> > перле в nginx. Это примерно также, как спорить с Сысоевым. Потому и
> > LOL.
> 
> Да? А мне кажется, что он только начинает и суть пока до конца не понимает.
> 
> И вообще, я сейчас единственный, кто занимается встроенным перлом в nginx,
> не видел в nginx-devel монсов всяких. И по-моему кроме Игоря, там вообще
> никого перл модуль не волнует.
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
> 
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111031/643d369f/attachment.html>

From vovkasm на gmail.com  Sun Oct 30 14:41:23 2011
From: vovkasm на gmail.com (Vladimir Timofeev)
Date: Mon, 31 Oct 2011 01:41:23 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIEhUTUwg0Lgg0LLQvtC+0LHRidC1?=
In-Reply-To: <20111030143035.GB2216@rabbit.us>
References: <20111028090209.GK20514@apache.rbscorp.ru>
	<20111028101532.GK24610@rabbit.us>
	<20111028110809.GN20514@apache.rbscorp.ru>
	<CANVWn7EKDrmjN2fNDdAWwTBLqAjY5-jRt4pHH0THNXonGw7M+A@mail.gmail.com>
	<5A026489-2587-4F1B-9E11-D15C12834486@aaanet.ru>
	<CANVWn7Ez-4u-ju7oGigrnc2ZjNvM2Bwkt53ueDzViEUeAtt7Vw@mail.gmail.com>
	<20111028115949.GZ24610@rabbit.us>
	<22C06B3C-76F7-4DC3-AAD1-7C426D734527@rambler-co.ru>
	<20111029020930.GA24861@rabbit.us>
	<E440520D-6A6C-427E-AE1C-30569F9C1418@rambler-co.ru>
	<20111030143035.GB2216@rabbit.us>
Message-ID: <CA+PuGkN+nD03bHMfYYfCHBGvKTKetEn349M7yn-75g5oR4W-UA@mail.gmail.com>

30 октября 2011 г. 18:30 пользователь Peter Rabbitson
<rabbit+moscowpm на rabbit.us> написал:
> On Sat, Oct 29, 2011 at 03:28:09PM +0400, Mons Anderson wrote:
>> Поищу )
>>
>
> Обязательно поищи! Даже если не понравится, то доведем до ума и выложим
> куда следует. Почему-то складывается впечатление что те которых скорость
> волнует решили что с маинтаинерами нечего даже разговаривать. Мы тоже
> люди, некоторые даже русские: тоже любим быстро ездить :)

Последнее, что у меня по этому поводу было сделано, лежит на github.
https://github.com/vovkasm/Class-Accessor-Inherited-XS

Что не сделано:
1. Многопоточность (т.к. мы используем перл в одном потоке, то даже не
пытались заморачиваться этой проблемой)
2. Документация
3. Интерфейс - все еще под вопросом (там в XS.pm "dirty hack" для того
чтобы вклиниться в Class::Accessor::Grouped)
4. В Class::XSAccessor используется очень интересная техника
оптимизации через custom OPs, до этого тоже дело еще не дошло.
5. Ну и "на свой страх и риск", не помню на чем я остановился, но там
были баги! (несмотря на это DBIC свои функциональные тесты проходит)

Чтобы быстро проверить это в готовом проекте на DBIC, надо в
DBIx/Class/AccessorGroup.pm заменить:
use base qw/Class::Accessor::Grouped/;
на
use base qw/Class::Accessor::Inherited::XS Class::Accessor::Grouped/;

Может быть Mons дальше продвинулся...

-- 
Vladimir Timofeev <vovkasm на gmail.com>

From dsimonov на gmail.com  Sun Oct 30 14:50:50 2011
From: dsimonov на gmail.com (Dmitry Simonov)
Date: Mon, 31 Oct 2011 01:50:50 +0400
Subject: [Moscow.pm] =?utf-8?b?0KDQsNC30LzRi9GI0LvQtdC90LjRjyDQvdCwINGC?=
	=?utf-8?b?0LXQvNGDIE9STSDQuCDQstC+0L7QsdGJ0LUg0YDQsNCx0L7RgtGLINGB?=
	=?utf-8?b?INCR0JQ=?=
In-Reply-To: <1979D6B0-8364-4C47-BC75-0495DDC21223@gmail.com>
References: <CAKb9G9gFJhBrddvXm9hBwYcX2FPoEoyZLTLTj6haPwKEEB+42g@mail.gmail.com>
	<6230E835-C5C9-4DDB-B2BF-5A4C2F5E8B0C@rambler-co.ru>
	<CAKb9G9gfcsmO2oNL2cvCED6pHL0zU+nns-VyGJLSU+ynp-tKmg@mail.gmail.com>
	<CAFtO3fk=MraZ9xSQRUmEhvXkYfQec3CHq+XGQ_5En9QiR5t9Rg@mail.gmail.com>
	<CAKb9G9h2buQbb7ozQ=3DU6Jc25NkEp3hyruAnKbhp2HZkaMbZA@mail.gmail.com>
	<CAL9wMxUrDjuh14cvt0xjK9PF=XVVe7qFY7z8LZictTZ1HoGiAQ@mail.gmail.com>
	<CAKb9G9j_dwuqQpmsY9q6ygh8f8Z+ZCNhOq=cgexBxrGWr3cCDQ@mail.gmail.com>
	<CAL9wMxU15_ArY+SJa57Vf1bdy2f=o-H6YHmt27w9eBkaLa6Xzw@mail.gmail.com>
	<CAKb9G9hNUB2Ute7bxP-Bd0tDRb0Fnf-_ew=9mSnbX_mgUwzHCA@mail.gmail.com>
	<CAL9wMxWQw3g7cQdih0-_zH=__=CVtkprwROQmrpV8owa7Uh7ag@mail.gmail.com>
	<CAKb9G9hCOQWVygbLSoen61Rpm0_ej+oFCxqbF6NBeivfgV-6UA@mail.gmail.com>
	<CAGOcgF3w=9C180Z0iqAPTruCb6NH8oa+A5VPA=Er6tM2ta2CRA@mail.gmail.com>
	<1979D6B0-8364-4C47-BC75-0495DDC21223@gmail.com>
Message-ID: <CAL9wMxWpqtTvqvseuQ8UYkRHL4sWmc23up3RiwGZ0QBc2174JQ@mail.gmail.com>

Поклясться не возьмусь, но от людей я слышал,Что раньше великаны
плодились на земле.Но дни былых племен затеряны во мгле,А в брошенных
домах живут, представьте, мыши...

---
Dmitriy V. Simonov,
Perl & Python programmer



2011/10/31 Denis Fedoseev <denis.fedoseev на gmail.com>:
> Ну в теории он может быть полезен для всяких шалобушек типа "+1" и прочей
> фигни, для которой сейчас используют ноду. Но на практике надо тестить что у
> этой конструкции будет с производительностью.
>
> On Oct 31, 2011, at 1:26 AM, Akzhan Abdulin wrote:
>
> Perl в nginx - не пришей кобыле хвост. полезен только для какой-то
> встроенной логики.
> Кстати, недавно модуль lua под nginx вышел - из той же оперы. как и v8.
> Если делаете с его помощью что-то большее, - вы сами себе злобный буратино.
> Причина - устройство событийной машины, которая лежит в основе архитектуры
> nginx.
> 30 октября 2011 г. 22:36 пользователь Alexandr Gomoliako <zzz на zzz.org.ua>
> написал:
>>
>> On Sun, Oct 30, 2011 at 8:20 PM, Dmitry Simonov <dsimonov на gmail.com>
>> wrote:
>> > Что касается Монса и Твоих наездов на него по поводу разработки на
>> > перле в nginx. Это примерно также, как спорить с Сысоевым. Потому и
>> > LOL.
>>
>> Да? А мне кажется, что он только начинает и суть пока до конца не
>> понимает.
>>
>> И вообще, я сейчас единственный, кто занимается встроенным перлом в nginx,
>> не видел в nginx-devel монсов всяких. И по-моему кроме Игоря, там вообще
>> никого перл модуль не волнует.
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>

From chesnokov.ilya на gmail.com  Mon Oct 31 03:16:12 2011
From: chesnokov.ilya на gmail.com (Ilya Chesnokov)
Date: Mon, 31 Oct 2011 14:16:12 +0400
Subject: [Moscow.pm] =?utf-8?b?0J7RgtC60LvRjtGH0LXQvdC40LUgd2FybmluZ3Mg?=
	=?utf-8?q?=27uninitialized=27?=
In-Reply-To: <CAJG5KK4hL0HXnLPLfoFpDPJ=NxwdSMw0MSqkJr0S+KCyphECkg@mail.gmail.com>
References: <CANh0x-ys4e308G4mP_MnPXhNKO4SZ5qZp5bjjcrLNc1BvZBBzQ@mail.gmail.com>
	<CALE3dTUiM6XuPGVFMuPVLVZb9hO2rZ4ff8JgMsBF4dT=BAyWCg@mail.gmail.com>
	<CANh0x-xLAFRa-LoPsL1-Vd7hVvi-mU05B64uqkKBmyuyDzSHQA@mail.gmail.com>
	<20111028114917.GY24610@rabbit.us>
	<CANh0x-yHG9Y+4xygW3SVLm9-sfZNCdabJAsLHBON0Vt3V8su5A@mail.gmail.com>
	<CAJG5KK4hL0HXnLPLfoFpDPJ=NxwdSMw0MSqkJr0S+KCyphECkg@mail.gmail.com>
Message-ID: <CANh0x-xp2iB-Ht3y4YrKt649+abyHJE9n3LQqa_LMneZtCjbvg@mail.gmail.com>

29 октября 2011 г. 1:34 пользователь Анатолий Шарифулин
<sharifulin на gmail.com> написал:
> 2011/10/28 Ilya Chesnokov <chesnokov.ilya на gmail.com>
>>
> Если это приводит к ошибке, то либо вы об этом узнаете как об ошибке, либо
> не узнаете никогда.
> Остаётся один только вопрос: цена ошибки, но это не в рамках обсуждения
> 'uninitialized'.
> Незачем тратить своё время на попытку написать идеальный код или покурыть
> тестами "каждый чих", это невозможно.
> А писать красивый компактный код, обрезав "лишнее" ? это и приятно, и
> полезно.

Анатолий, спасибо за комментарий :)

> Вот это крутая тема, если есть время это разбирать и исправлять каждый день, то вы лучшая команда по поддержке кода (по крайней мере, стремитесь к этому).

В-общем, как раз из-за этой самой "крутой темы" мы решили в итоге
отказаться от отключения варнингов и пойти на жертву, замедляя свой
код проверками через defined() -- всё же на поверку выходит, что баги
иногда ловятся самые неожиданные, поэтому приходится жертвовать время
на разбор полётов.

-- 
Best regards,
Ilya Chesnokov