|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
Андрей ПанфиловНе особо вяжется с этой мурзилкой: Вы чего хотели выразить? Впрочем, неважно. Вяжется. Но приходится ещё раз предупредить, что Documentum - не для лохов, значит и не для вас, если только вы не относитесь к интеграторам, которые впаривают лохам фуфло. Тогда для вас. Хотя тоже вряд ли, потому что следующая цитата из вас - полная чушь, показывающая незнакомство с темой: Андрей ПанфиловВ итоге то что действительно похороили - xCP, но лично мне изначально казалось что он не жилец особо, к нам как-то приходил сейл из EMC и пытался впарить коробку EPFM, проблема в том, что EPFM начали делать через год-два после появления xCP, вот только проблема в том, что сделано оно на webtop, что говорит само за себя о возможностях xCP. МихаилРОтдельное спасибо за ремару по поводу Alfresco. Про Alfresco лучше узнайте у тех, кто сам знает. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2014, 14:58 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
Андрей Панфилов(мы для внутренних целей используем альфреску, причем в наличии есть грамотные разработчики, впечатление такое, что коробочный webtop куда функциональнее и удобнее чем альфреска, кроме этого по отзывам разработчиков складывается впечатление, что альфреска представляет из себя некий фарш из жавы и сервеного жаваскрипта, кроме этого база используется как EAV, так что с отчетами и поиском ой какая беда) Это я процитировал для подтверждения своего высказывания, что об Alfresco надо узнавать у тех, кто знает, а здесь таких нет. Если отбросить словесный мусор, то правда в этом тексте состояла в том, что кроме Java API существует JavaScript API. Пользоваться им необязательно, но ничего плохого нет в том, что предоставлена такая возможность. Тут ещё было мнение, что автоматические активности пишутся на JavaScript. Тоже нобязательно - есть разные виды: можно на Java, можно на скриптовом языке (часто используются JavaScript и Groovy, но можно и другие на платформе Java). В общем. Я изучаю Alfresco по документации, что и другим советую, а с вопросами можно обращаться к интеграторам. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2014, 15:14 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
Андрей Панфиловкрупных заказчиков не осталось, а мелким Documentum не нужен. Заказчиков можно понять. Тоже самое можно сделать гораздо разумнее и проще. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2014, 16:11 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
Partisan MВяжется.конечно, Ваше утверждение "я знаю документум" и 10985752 корелируют с коэффициентом -1. Partisan MТранзакции в Документуме есть, и длинные и короткие (только они так не называются). Длинные реализуются как жизненные циклы (lifecycle). Жизненный цикл это последовательность состояний объекта, состояние - согласованный набор атрибутов (параметров). Контроль согласованности осуществляется: как без программирования (заданием условий вхождения в состояние), так и с ним (отдельной процедурой жизненного цикла, написанной на Java или языке DocBasic). Partisan MОни связаны с блокировками (lock) объектов. Есть нескольуо уровней блокировки, на самом строгом она осуществляется и на уровне базы данных. Эти уровни: - самая слабая - метод fetch () в классе IDfPersistentObject. Не обеспечивает закрепления объекта за одним пользователем (другие могут менять), а только получение последней версии. - затем выписка (checkout(), checkin(), save(), savelock()) - это блокировка для редактирования одним пользователем, осуществляется Content Server-ом с помощью "неявной транзакции" на уровне хранилища (не базы данных) - явные транзакции, то есть запрограммированные в приложении. Они помогают добавить проверку согласованности атрибутов перед сохранинием. Осуществляются с помощью beginTransaction () в классе IDfSessionManager (посмотреть также описание "сессий" и при знании Java - документацию JavaDoc по DFC по этим классам). То, что в Документуме называется транзакциями - явные и неявные, осуществляются Content Server-ом, то есть на уровне хранилища. - блокировка на уровне СУБД (самая строгая), нужна редко, происходит если вызвать метод lock () или lockEx () класса IDfPersistentObject. Это предотвращает неудачу записи изменённого объекта если он во время редактирования изменялся ещё и автоматически Документумом. Итак, для "транзакции БД" нужно вызывать метод lockEх() внутри транзакции, начатой по beginTransaction(). Это бывает нужно редко (мне ни разу не понадобилось), но разработчики должны разбираться в методах блокировки и правильно применять нужные. Транзакции к блокировкам никакого отношения не имеют, разве что пессимистичную блокировку можно сделать только в транзакции. Жавский вызов fetch() - это вообще не блокировка, а жавский метод, актуализирующий текущее состояние объекта с СУБД. При этом на клиент запоминает текущий i_vstamp объекта (по факту счетчик сохранений) и при вызове save() передает запомненное значение обратно контет-серверу, тот в свою очередь сохраняет изменения в СУБД примерно таким вот запросом: Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
Если запрос не обновил ни одной строки (т.е. в базе нет совпадений для пары (r_object_id, i_vstamp)), то контент выкидывает клиенту ошибку DM_OBJ_MGR_E_VERSION_MISMATCH. То что описано выше - реализация оптимистичной блокировки, не более и не менее. К транзакициям это имеет ровно только одно отношение: контент-сервер инвалидирует транзакцию в случае возниковения ошибки: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24.
checkout() - метод, предназначенный для закрепления права редактирования документа (свойств и контента) за определенным пользователем, вся магия, которая в нем делается - выставление атрибутов r_lock_owner, r_lock_date и r_lock_machine (последний полезен разве что в случае нескольких серверов, обслуживающих один репозиторий), дальше идет исключительно конвенция - если атрибут r_lock_owner не пустой и не равен имени текущего пользователя, то текущий пользователь не может вносить изменения в объект. Ввиду того, что это просто конвенция, то реализовать какие-либо блокировки на ней нельзя. Справедливости ради нужно сказать, что индусы-разработчики также полагают, что checkout() реализует блокировку, хотя это не так, пример как две сессии успешно "блокируют" объект одновременно: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
checkin() - метод, определяющий ветвление версий, save() - сохранение объекта в СУБД со снятием флага r_lock_owner, если таковой взведен, saveLock() - сохранение объекта в СУБД без снятия флага r_lock_owner. Вообщем тут опять не про транзакции. До DFC6, действительно, транзакцию можно было начать только в менеджере сессий, но при именно при этом вызове транзакция начитается в жавском коде, транзакции, начатые через менеджер сессий реализуют только часть XA - сам лично заводил дефекты, когда в одной сессии изменения сохраняются в СУБД, а во второй - облом. Начиная с DFC6 транзакции можно начинать на уровне сессии, при этом все последующие RPC будут идти в транзакции. Но тут есть один довольно плохой момент - транзакции также вяжутся к жавскому-потоку, поэтому выполять траезакционный код можно только в одном потоке. lock() - жавский метод, заставляющий контент-сервер выпонять такой запрос: Код: sql 1. 2. 3.
Т.е. по сути в СУБД на строку накладывается row-level lock, больше никакой магии тут нет. Поскольку row-level lock можно снять только либо закоммитив либо прервав транзакцию, то метод lock() должен выполняться в транзакции (чисто формально такое ограничение накладывает только DFC, а не контент-сервер, поэтому можно извернуться явно транзакцию не начинать, то смысла это не несет). lockEx() от lock() отличается только тем, что позволяет узнать модифицировался ли объект пока вызвов lockEx() пытался заблокировать строку или нет, что само по себе смысла никакого не имеет, потому что типичый паттерн исподьзования lock() выглядит так: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24.
PS. довольо опрометчиво называть человека, который знает документум вдоль и поперек, написал собственные реализации протокола на perl и python, лохом - можно и говна нажраться Partisan MЕсли отбросить словесный мусор, то правда в этом тексте состояла в том, что кроме Java API существует JavaScript API. Пользоваться им необязательно, но ничего плохого нет в том, что предоставлена такая возможность. Конечно, можете еще рассказать как там полностью отсуствует поиск по значениям атрибутов - можно использовать только полнотекстовый lucene, также расскажите как альфреска начинает замечательно глючить, если вдруг полнотекстовый индекс похерился. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2014, 16:50 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
Андрей ПанфиловPartisan MВяжется.конечно, Ваше утверждение "я знаю документум" и 10985752 корелируют с коэффициентом -1. а что в том тексте вас смущает кстати? А то вы уже второй раз его приводите, но при этом и слова не сказали что-же в нем неправильного ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2014, 16:55 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
iscrafmЗаказчиков можно понять. Тоже самое можно сделать гораздо разумнее и проще.Главное чтобы заказчик понимал что он действительно хочет, а тут зачастую бывает что ФЗ - делопроизводы, требования пишут IT, а на выходе крокодил. Делать маленькие проекты на документуме смысла нет - они будут задействовать от силы процетов 10 функциональности платформы, а бабки за лицензии будут платиться за то, что успели написать индусы за много лет. Сейчас обещают сделать бесплатный (соответствено неподдерживаемый) порт на postgresql, если сделают на основе прямого билда, то по лицензиям можно довольно сильно упасть будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2014, 17:06 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
iscrafmа что в том тексте вас смущает кстати? А то вы уже второй раз его приводите, но при этом и слова не сказали что-же в нем неправильногоВ целом - все, под спойлером написано почему. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2014, 17:07 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
Андрей ПанфиловiscrafmЗаказчиков можно понять. Тоже самое можно сделать гораздо разумнее и проще.Главное чтобы заказчик понимал что он действительно хочет, а тут зачастую бывает что ФЗ - делопроизводы, требования пишут IT, а на выходе крокодил. Делать маленькие проекты на документуме смысла нет - они будут задействовать от силы процетов 10 функциональности платформы, а бабки за лицензии будут платиться за то, что успели написать индусы за много лет. Сейчас обещают сделать бесплатный (соответствено неподдерживаемый) порт на postgresql, если сделают на основе прямого билда, то по лицензиям можно довольно сильно упасть будет. делать маленькие проекты на нем смысла нет по другой причине, выше озвучил: тоже самое можно сделать другими средствами проще и разумней. Возможности Documеntum здесь не причем. Как у любого монстрообразного продукта, разрабатываемого разными коллективами и в разные годы - родовая травма: сборная солянка. Поэтому ввязываться можно только если проект огромный, по причине отсутствия проверенных предложений ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2014, 17:11 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
Андрей Панфиловiscrafmа что в том тексте вас смущает кстати? А то вы уже второй раз его приводите, но при этом и слова не сказали что-же в нем неправильногоВ целом - все, под спойлером написано почему. под спойлером программерские рассуждения на туже тему. Вы наверное не совсем поняли о чем оппонент говорил и тоже самое с кучей кода зачем-то привели ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2014, 17:13 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
iscrafmпод спойлером программерские рассуждения на туже тему. Вы наверное не совсем поняли о чем оппонент говорил и тоже самое с кучей кода зачем-то привелиВ каком месте вы считаете, что то же самое? авторсамая слабая (блокирвка) - метод fetch () в классе IDfPersistentObject бред, пояснил по какой причине. авторзатем выпискабред, пояснил по какой причине. и т.д. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2014, 17:21 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
Андрей Панфиловавторсамая слабая (блокирвка) - метод fetch () в классе IDfPersistentObject бред, пояснил по какой причине. я заметил что там тоже самое, но другими словами, с точки зрения кодера. Если для оппонента блокировка ресурса означает одно, то для вас - другое. Не более ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2014, 17:31 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
iscrafmя заметил что там тоже самое, но другими словами, с точки зрения кодера. Если для оппонента блокировка ресурса означает одно, то для вас - другое. Не болееТам топик исключительно про то, что почему пограмисты пишут хрень. Если вы пожете разумно пояснить почему fetch() (чтение актуального состояние объекта из СУБД) внезапно стал блокировкой, то я с Вами, пожалуй, соглашусь ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2014, 17:34 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
iscrafmАндрей Панфиловпропущено... бред, пояснил по какой причине. я заметил что там тоже самое, но другими словами, с точки зрения кодера. Если для оппонента блокировка ресурса означает одно, то для вас - другое. Не более т.е. вы понятие "блокировка" не воспринимаете дальше, чем его интерпретирует СУБД. То, что, например, пользователь закрепил за собой право распоряжаться каким-то объектом другим способом "блокировкой" уже по вашему не является. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2014, 17:35 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
iscrafmделать маленькие проекты на нем смысла нет по другой причине, выше озвучил: тоже самое можно сделать другими средствами проще и разумней. Возможности Documеntum здесь не причем. Как у любого монстрообразного продукта, разрабатываемого разными коллективами и в разные годы - родовая травма: сборная солянка. Поэтому ввязываться можно только если проект огромный, по причине отсутствия проверенных предложенийВы не могли бы развернуть свою мысль более подробно? Вот берем ядро: Content Server + DFC, это 474 вызова RPC в контент-сервере, некоторый набор базовых сущностей (пользователь, группа, папка, документ и пр.) + некий шлак в виде небазовых сущностей, которые впихнул вендор, чтобы можно было продать продукт без кастомизации + стек DFC, реализующий все RPC на клиенте и поддерживающий базовые правила работы с баовыми сущностями. Здесь вроде как солянки нет, за исключением того, что отмечено как "шлак" (который вроде как и не заметен особо), вместо солянки присуствует куча legacy-функционала (например те же жизненные циклы), который убрать нельзя, потому что текущие заказчики дадут п.ды. Дальше BPM: 6 (могу ошибаться) вариантов выбора исполнителей активностей, 2 вида активностей (ручные/автоматические), пара десятков предустановленных шаблонов активностей - в целом ничего лишнего нет, наблюдается скорее отсуствие функционала (ну например встроенных decision rules ой как не хватат). Webtop - здесь да, проблема: в коде нет вообще никакой конвенции, разные компоненты реализованы по-разному (в плане конвенции), что творится в кастомизациях партнеров вообще уму непостижимо. xCP/xCP2/D2 - точно без солянки, но у них родовая травма другого рода - кода как такового нет, потому что предполагается большую часть функционала реализовывать настройками, соответсвенно СКВ не прикручивается, найти почему что-то работает не так как нужно - упаришься. DFS/CMIS/REST - ну это просто сервисы, реализующие некоторую часть DFC, то что сверху - ответственность исполнителя. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2014, 17:44 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
т.е. разница только в том, что ваш оппонент назвал гарантированное чтение объекта с обеспечение его логической целостности на данный момент времени "блокировкой", в терминах. По большому счету это можно назвать кратковременной блокировкой на момент чтения, гарантированно получить целостный объект ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2014, 17:45 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
Андрей Панфилову них родовая травма другого рода - кода как такового нет, потому что предполагается большую часть функционала реализовывать настройками, соответсвенно СКВ не прикручивается, найти почему что-то работает не так как нужно - упаришься . это и имеется ввиду. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2014, 17:49 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
iscrafmт.е. вы понятие "блокировка" не воспринимаете дальше, чем его интерпретирует СУБД. То, что, например, пользователь закрепил за собой право распоряжаться каким-то объектом другим способом "блокировкой" уже по вашему не является.Почему же не воспринимаю? Оно для пользователя выглядит так: если никто не выписал, то значка нет, если выписал текущий пользователь, то ключик, если не текущий - замочек. Т.е. в зависимости от того, какое значение атрибута, пользователь видит ту или иную иконку, и лишний раз никуда не лезет, т.е. для бизнес-пользователя оно работает ожидаемо, но авторэто блокировка для редактирования одним пользователем, осуществляется Content Server-ом с помощью "неявной транзакции" на уровне хранилища (не базы данных) бред. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2014, 17:51 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
iscrafmт.е. разница только в том, что ваш оппонент назвал гарантированное чтение объекта с обеспечение его логической целостности на данный момент времени "блокировкой", в терминах. По большому счету это можно назвать кратковременной блокировкой на момент чтения, гарантированно получить целостный объектВообще совершенно разные понятия. Вы приходите в магазин смотрите сколько стоит арбуз и сколько примерно есть - это fetch, никакой блокировкой тут не пахнет, дальше подходите к продавцу и просите принести 10 арбузов (вы прикинули что десяток точно наберется), продавец ушел за арбузом - Вы пессимистичо заблокировали продавца (его никто больше использовать не может), пока продавец ходил арбузы разобали и осталось 9, он приходит и говорит: "Осталось 9" - это оптимистичная блокировка, Вы в праве решить брать 9 или уйти, что там Вы видели в начале своей бизнес-транзакции никого не волнует - нужно было резервировать нужное количество в самом начале (пессимистичная блокировка) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2014, 18:11 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
iscrafmАндрей Панфилову них родовая травма другого рода - кода как такового нет, потому что предполагается большую часть функционала реализовывать настройками, соответсвенно СКВ не прикручивается, найти почему что-то работает не так как нужно - упаришься . это и имеется ввиду.Дык у этих продуктов целевая аудитория как раз мелкие заказчики (с оговоркой на то, что продаванам нужно продавать и они впаривают все подряд без разбора, а заказчик не поимает к чему это приведет). ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2014, 18:13 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
хорошо. давайте на бытовых примерах. покупатель желает белый халат в красной коробке. Белый халат в красной коробке - это объект. Вопрос покупателя продавцу о таком объекте - это вызов fetch. Ответ продавца - это возрат fetch. Так вот пока продавец идет из подсобки с ответом - действует блокировка белого халата в красной коробке, чтобы когда продавец дойдет до покупателя с ответом не случилось конфуза: пока он шел забрали или белый халат или красную коробку для того, чтобы положить в нее зеленый халат. Это просто чтение с гарантированно целостным ответом. Блокировка действует мгновение, пока продавец не ответит. Потом, пока покупатель будет думать брать или не брать конечно ничего в данном варианте не блокируется. Обычное гарантированное чтение READ COMMITED, если в термины СУБД перевести ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2014, 18:34 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
iscrafmхорошо. давайте на бытовых примерах. ...У Вас пример несколько натянут для того, чтобы попытаться приплести RC к блокировке, ну нет там блокировки и все. Кроме этого гаратий тоже нет никаких: пока продавец выходил в подсобку халат украли, клиент данные вроде как получил, которые были консистентны мгновение назад, но смысла в них нет никакого. В документуме работает по-умолчанию оптимистичная блокировка, но реализуется она двумя вызовами: fetch() (который с клову сказать бывает неявным и бывает холостым) и save(). ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2014, 18:54 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
Андрей Панфиловпока продавец выходил в подсобку халат украли, клиент данные вроде как получил, которые были консистентны мгновение назад, но смысла в них нет никакого. есть ли в них смысл или нет - другой вопрос. Здесь важно то, что на время ответа (это самое мгновение назад) должна быть гарантия правильности ответа. Иначе обычное "грязное" чтение. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2014, 19:20 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
iscrafm, ну ответ пришел консистентный, только где блокировка-то? в базе ее нет, с т.з. пользователя ее тоже нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2014, 19:28 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
Андрей Панфиловбред. Модератор: Уважаемый Андрей Панфилов, очень Вас прошу избегать подобных "интегральных оценок" высказываниям иных участников обсуждения. Это накаляет атмосферу и, откровенно говоря, не красит Вас лично, демонстрируя Ваши амбиции. Высказывайте, пожалуйста, аргументы, а не выставляйте оценки. Тем более, как показывает обсуждение с iscrafm, Вы и сами не до конца понимаете, о чем идет речь. При неоднократном чтении атрибутов одного и того же объекта можно именно на операциях чтения "заявить", допускается, либо не допускается изменение атрибутов объекта за пределами транзакции, только в зафиксированных транзакциях или в незафиксированных тоже и, соответственно, при повторных чтениях внутри текущей транзакции будут допускаться или не будут допускаться изменения атрибутов объекта внешними зафиксированными транзакциями, либо незафиксированными транзакциями ("грязное чтение"). И это тоже разновидность блокировки, а вовсе не "бред". Заносчивость иногда играет злую шутку с теми, кем она овладела. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2014, 17:33 |
|
Состааввление требований к исключению Documentum и OpenText
|
|||
---|---|---|---|
#18+
Garya, Я хотел бы обратить Ваше внимание на то, что обсуждается вполне определеный продукт, работающий со вполне определенными СУБД с вполне определенными (вендором) настройками. Для ORACLE UR вообще нет, для MSSQL рекомедуется READ_COMMITTED_SNAPSHOT=ON, поэтому все гипотетические предположения о том, что продукт (т.е. documentum) при реализации определенных RPC накладывает блокировки в СУБД, остаются гипотетическими. Можно скольку угодно пытаться найти хоть какую-то истину в изначально неверном утверждении, но ни к чему толковому это не приведет. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2014, 18:59 |
|
|
start [/forum/topic.php?fid=29&msg=38530584&tid=1525917]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
39ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
73ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 167ms |
0 / 0 |