1) Покажите, пожалуйста, строчку кода, которая выполняется не в главном потоке.
2) Откуда информация, что главный поток занят? Что вам мешает повторно нажать на кнопочку "Async" во время "вычислений"?
Добавил логирование сообщения на выход из обработчика нажатия:
procedure TExample.btStartAsyncClick(Sender: TObject);
begin
// mmLog.Clear;
TCalcAsync.Create.Switch; Log('btStartAsyncClick finish', []);
end;
Дважды быстро нажал на "Async". Получил лог (обратите внимание на положение этого сообщения — оно между сообщениями из TCalcAsync.Execute):
Хочу ещё предостеречь, что в документации docwiki.embarcadero.com/RADStudio/XE5/en/Operator_Overloading_%28Delphi%29
чётко сказано, что все логические операции (=, <>) должны возвращать Boolean. Т.е. в данном подходе используется недокументированная особенность компилятора, а значит у Embarcadero остаётся полное моральное право изменить поведение компилятора согласно документации. А в больших проектах, которые планируются партироваться на ещё не существующие версии Delphi, необходимо предусмотреть способ отказаться от недокументированных возможностей. Но тут же начальство можно успокоить:
1) Я уверен, что этот подход (кстати, он прокатывает и на C#, только смысла в нём там меньше) заиспотьзуют большенство ORM-ов. Embarcadero придётся поддержать существующее поведение компилятора в будущем.
2) Если что-то пойдёт не так, возьмём наш парсер Паскаля и заменим "=, <>" на вызовы обычных функций. Будет не так красиво смотрться, но работать будет.
Почему вы считатете, что выражение
(P.Father = F.ID) and… and (P.Mother <> 20)
может генерировать только SQL. SQL был взят для простоты восприятия.
В реальном проекте генерируется не SQL, а объектную модель условия выборки для ORM, которая передаётся на Application Server и там модифицируетя\дополняется. И только потом трансформируется в SQL.
Т.е. этот подход не заменяет ORM, а дополняет одну из слабых их мест (по состоянию лет 7 назад) — генерацию динамического уловия под контролем компилятора. Т.е. следующая статья может называться «Эмуляция LINQ for mORMot Framework на Delphi».
Покажите, пожалуйста, как будет выглядеть генерация вышеуказанного условия на mORMot Framework engine.
2) Откуда информация, что главный поток занят? Что вам мешает повторно нажать на кнопочку "Async" во время "вычислений"?
Добавил логирование сообщения на выход из обработчика нажатия:
procedure TExample.btStartAsyncClick(Sender: TObject);
begin
// mmLog.Clear;
TCalcAsync.Create.Switch;
Log('btStartAsyncClick finish', []);
end;
Дважды быстро нажал на "Async". Получил лог (обратите внимание на положение этого сообщения — оно между сообщениями из TCalcAsync.Execute):
1 + 2 start
3 + 4 start
btStartAsyncClick finish
1 + 2 start
3 + 4 start
btStartAsyncClick finish
1 + 2 = 3
3 + 4 = 7
3 7 start
1 + 2 = 3
3 + 4 = 7
3 7 start
3 7 = 21
3 7 = 21
bugs.freepascal.org/view.php?id=25370
Хочу ещё предостеречь, что в документации
docwiki.embarcadero.com/RADStudio/XE5/en/Operator_Overloading_%28Delphi%29
чётко сказано, что все логические операции (=, <>) должны возвращать Boolean. Т.е. в данном подходе используется недокументированная особенность компилятора, а значит у Embarcadero остаётся полное моральное право изменить поведение компилятора согласно документации. А в больших проектах, которые планируются партироваться на ещё не существующие версии Delphi, необходимо предусмотреть способ отказаться от недокументированных возможностей. Но тут же начальство можно успокоить:
1) Я уверен, что этот подход (кстати, он прокатывает и на C#, только смысла в нём там меньше) заиспотьзуют большенство ORM-ов. Embarcadero придётся поддержать существующее поведение компилятора в будущем.
2) Если что-то пойдёт не так, возьмём наш парсер Паскаля и заменим "=, <>" на вызовы обычных функций. Будет не так красиво смотрться, но работать будет.
(P.Father = F.ID) and… and (P.Mother <> 20)
может генерировать только SQL. SQL был взят для простоты восприятия.
В реальном проекте генерируется не SQL, а объектную модель условия выборки для ORM, которая передаётся на Application Server и там модифицируетя\дополняется. И только потом трансформируется в SQL.
Т.е. этот подход не заменяет ORM, а дополняет одну из слабых их мест (по состоянию лет 7 назад) — генерацию динамического уловия под контролем компилятора. Т.е. следующая статья может называться «Эмуляция LINQ for mORMot Framework на Delphi».
Покажите, пожалуйста, как будет выглядеть генерация вышеуказанного условия на mORMot Framework engine.