The daily Axapta WTF - Страница 22 - Курилка

Stitch_MS · 05.09.2022, 16:40

X++:

BPUpgradeCodeSystemDate: BP Rule: [BPUpgradeCodeSystemDate]:Method systemdateget has been deprecated, use DateTimeUtil::getSystemDate(DateTimeUtil::getUserPreferredTimeZone()) instead.

Нельзя просто взять, и сделать так, чтобы systemDateGet вызывал DateTimeUtil::getSystemDate(DateTimeUtil::getUserPreferredTimeZone()).

"...
- Товарищ лейтенант, может, лучше лопатами?
- Мне не надо лучше, мне надо, чтобы вы замучились." (с)

axm2017 · 05.09.2022, 16:55

Цитата:

Сообщение от Stitch_MS

..
Нельзя просто взять, и сделать так, чтобы systemDateGet вызывал DateTimeUtil::getSystemDate(DateTimeUtil::getUserPreferredTimeZone()).

Если они не идентичны (так как кто, когда, зачем и что делал неизвестно) то это как раз нормально: типа не сломаем то что было

Stitch_MS · 05.09.2022, 17:59

Цитата:

Сообщение от axm2017

Если они не идентичны (так как кто, когда, зачем и что делал неизвестно) то это как раз нормально: типа не сломаем то что было

Хм, а ведь разница действительно есть. Сам писал про неё несколько лет назад.

Вкратце, systemDateSet "не влияет" на время суток, ну то-есть можно прибавлять и отнимать целые сутки, а часы и минуты будут тикать себе дальше, но это если потом использовать systemDateGet для проверки.

А вот если после systemDateSet или DateTimeUtil::setSystemDateTime вызывать DateTimeUtil::getSystemDateTime, то время "замрёт".

Logger · 05.09.2022, 22:15

Цитата:

Сообщение от Stitch_MS

А вот если после systemDateSet или DateTimeUtil::setSystemDateTime вызывать DateTimeUtil::getSystemDateTime, то время "замрёт".

А обратно "отмереть" время можно ?

Stitch_MS · 06.09.2022, 18:35

Цитата:

Сообщение от Logger

А обратно "отмереть" время можно ?

Хороший вопрос, но пока не копал — не было необходимости.

trud · 26.10.2022, 04:31

Кто там говорил что виртуальные компании это плохо и сложно настраивать, поэтому их и убирают
Похоже эту функциональность решили переизобрести, но под новым названием - master company sharing (preview)

https://learn.microsoft.com/en-us/dy...n/srs-overview

**sukhanchik** · 26.10.2022, 10:42

Цитата:

Сообщение от trud

Кто там говорил что виртуальные компании это плохо и сложно настраивать, поэтому их и убирают
Похоже эту функциональность решили переизобрести, но под новым названием - master company sharing (preview)

https://learn.microsoft.com/en-us/dy...n/srs-overview

Так это давно уже "изобрели". И на уровне свойства таблицы можно было задать - данные единые или копируемые. Детально я не проверял, но год назад точно работал только режим "копируемые".
Т.е. технически, если я допустим группу клиентов шарю между компаниями - то создается вторая запись (с другим RecId), которая является полной копией другой записи и любая попытка изменить любое поле - автоматически приводит к синхронизации второй записи. Это я и называю режим "копируемые". И даже приводились ограничения от MS на объем таких "синхронизируемых" данных.

Тут собственно 2 проблемы:
1. Единая запись и автоматически копируемая - это всё-таки разные технологии. И постоянная синхронизация явно не увеличивает производительность
2. Про ссылки по RecId в этом случае можно забыть. В системе же действительно очень мало ссылок по RecId

)) и конечно же этим ограничением можно пренебречь

)))

И мне так и не довелось увидеть в работе режим Single (свойство Data sharing type на таблице). Режим Duplicate - да, работает. Но как я уже писал с ограничением на объёмы синхронизируемых данных

axm2017 · 01.11.2022, 10:34

Табличка VendInvoiceInfoTable_RU
как понимаю под коррекцию создали поля
CorrectedInvoiceId_RU
CorrectedInvoiceDate_RU
CorrectedJournalId
но вижу перенос в VendInvoiceJour только первых двух полей что рождает порой неоднозначность
почему не перенесли и третье поле загадка

trud · 18.01.2023, 04:40

По ходу команда которая делала ГК еще осталась в MS и теперь они добрались и до InventTrans(у которой по видимому есть "фатальный недостаток")
Встречайте новые таблицы(пока только для склада) с GUID идентификаторами

Нажмите на изображение для увеличения
Название: NewInventTrans.png
Просмотров: 72
Размер: 196.3 Кб
ID: 13535

Оригинал вот здесь:
https://learn.microsoft.com/en-us/sh...y-transactions

ena_ax · 18.01.2023, 10:04

Цитата:

Сообщение от trud

По ходу команда которая делала ГК еще осталась в MS и теперь они добрались и до InventTrans(у которой по видимому есть "фатальный недостаток")
Встречайте новые таблицы(пока только для склада) с GUID идентификаторами

Вложение 13535

Оригинал вот здесь:
https://learn.microsoft.com/en-us/sh...y-transactions

Добрый день!
Для понимания, можете рассказать чем плохи или не удобны идентификаторы GUID?

Владимир Максимов · 18.01.2023, 12:11

Цитата:

Сообщение от ena_ax

Для понимания, можете рассказать чем плохи или не удобны идентификаторы GUID?

Есть правило: пусть безобразно, зато единообразно

Это означает, что все приложение должно строится по одним и тем же правилам (принципам). Что позволяет существенно упростить сопровождение такого приложения. Пусть и может приводить к некоторым проблемам

К сожалению, в отношении Axapta это правило уже давно нарушено. Сейчас с точки зрения именно идеологии построения приложения Axapta представляет собой не единый "монолит", а некую "сборную солянку", что существенно усложняет сопровождение.

Так вот, использование GUID как идентификатора записи в одном модуле - это еще одно нарушение "монолитности" (единообразия) идеологии. Дополнительная проблема при внесении изменений в код.

Хотя в данном случае, вроде бы, речь идет не об идентификаторе записи (RecId), а о некоем общем идентификаторе "процесса" вроде ParmId. Т.е. вроде бы, и не выбивается из общих принципов построения приложения в данном случае.

trud · 18.01.2023, 16:05

Цитата:

Сообщение от Владимир Максимов

Хотя в данном случае, вроде бы, речь идет не об идентификаторе записи (RecId), а о некоем общем идентификаторе "процесса" вроде ParmId. Т.е. вроде бы, и не выбивается из общих принципов построения приложения в данном случае.

Ну да, собственно Владимир ответил. Т.е. в системе есть некие принципы, если что-то нумеровать, можно использовать номерную серию. Номерные серии - это довольно крутой механизм, заложенный в системе, как раз для проблемы нумерации.
Если использовали GUID - опять же, могу ошибаться, но тут скорее всего пришли люди которые с системой до этого не работали(не знают что такое номерные серии), и начали проектировать данные таблицы.
Можно конечно предположить, ну ладно, системы не знают, но наверное технически специалисты хорошие. Но в этом заставляет сомневаться вот такие графики в презентации (нет подписей для оси Х и У, непонятно что вообще проверяли)

Нажмите на изображение для увеличения
Название: PerformanceImpr.png
Просмотров: 55
Размер: 41.5 Кб
ID: 13536

Плюс я немного работал над оптимизаций складов, и я никогда не видел в топе нагрузки запросы связанные именно с InventTrans, а те что были, они бы к примеру выиграли от денормализации InventTrans, добавления к примеру туда всех полей аналитик(но тут явно обратный процесс)

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

ТРЕНЕР · 18.01.2023, 17:24

Цитата:

Сообщение от trud

(у которой по видимому есть "фатальный недостаток")

На скриншоте в первой таблице написано Tranasctions вместо Transactions.
Это фатальный недостаток команды в целом.

Logger · 18.01.2023, 21:07

Цитата:

Сообщение от ТРЕНЕР

На скриншоте в первой таблице написано Tranasctions вместо Transactions.
Это фатальный недостаток команды в целом.

Ну мы же жили много лет с PostingProgile - ом и никто не умер.

Но конечно тоже резануло глаз.

Pandasama · 18.01.2023, 10:33

Цитата:

Для понимания, можете рассказать чем плохи или не удобны идентификаторы GUID?

Они не плохи, но, думаю, здесь избыточны. Больший размер чем у RecId, дольше генерятся.

Logger · 18.01.2023, 10:43

Цитата:

Сообщение от Pandasama

Они не плохи, но, думаю, здесь избыточны. Больший размер чем у RecId, дольше генерятся.

А еще по ним индексы неэффективно работают.
Фрагментация, то, сё...

**fed** · 18.01.2023, 11:08

Цитата:

Сообщение от Logger

А еще по ним индексы неэффективно работают.
Фрагментация, то, сё...

Вообще в SQL Server есть функция, которая возрастающие GUID генерирует. (NewSequentialId()), по которым проблемы фрагментации индекса не возникает. Тут правда вопрос - как разработчики GUIDы в своей логике генерируют...
Плюс - мне кажется что сейчас почти все индексы сжимаются, при этом с учетом того что они пишут что у них таблица в режиме append only, особо большого оверхида при обновлениях не будет, а при чтении за счет сжатия выигрыш будет существенным.

Logger · 18.01.2023, 13:27

Цитата:

Сообщение от fed

Вообще в SQL Server есть функция, которая возрастающие GUID генерирует. (NewSequentialId()), по которым проблемы фрагментации индекса не возникает.

Это да.
Но если их инкрементно выделять, то пропадают все вкусности GUID и он становится ничем не лучше обычного RecId. Даже хуже, так как RecId всего 8 байт занимает.

**fed** · 18.01.2023, 14:11

Цитата:

Сообщение от Logger

Это да.
Но если их инкрементно выделять, то пропадают все вкусности GUID и он становится ничем не лучше обычного RecId. Даже хуже, так как RecId всего 8 байт занимает.

GUID проще выделить до записи в БД. То есть - в принципе UnitOfWork или махинации с suspendRecId() решают проблему, но MkGuid() все равно проще написать.

Logger · 12.09.2023, 14:32

Цитата:

Сообщение от Logger

Это да.
Но если их инкрементно выделять, то пропадают все вкусности GUID и он становится ничем не лучше обычного RecId. Даже хуже, так как RecId всего 8 байт занимает.

Оказывается подготовлен стандарт UUIDv7, свободный от перечисленных мной недостатков.

https://habr.com/ru/articles/658855/

Комменты, как обычно, еще интереснее.