DG
а если придираться, то приведение типа не есть функция, поэтому правильный ответ
intval, а не (int) :Ря предложил вариант с str_replace, если придираться 😉
Size: a a a
2020 March 04
А
я предложил вариант с str_replace, если придираться 😉
не гибко
DG
не гибко
бизнес задача не требует гибкости, решение покрывает требования на 100%
Покрыть тестами и в прод!
Покрыть тестами и в прод!
А
бизнес задача не требует гибкости, решение покрывает требования на 100%
Покрыть тестами и в прод!
Покрыть тестами и в прод!
а, так бизнесу надо
e2 на 00 менять, а не раскрывать экспоненциальную запись числа? :)DG
а, так бизнесу надо
e2 на 00 менять, а не раскрывать экспоненциальную запись числа? :)вполне, или вы докажете обратное?
DD
знает кто хорошую либу под deeplink-и для android и iOS? на packagist-е чёт всё малозвёздно-малоскачиваемо
МГ
может сессия помирает/сессионная куки экспайрится?
так оно и есть но почему?
AN
знает кто хорошую либу под deeplink-и для android и iOS? на packagist-е чёт всё малозвёздно-малоскачиваемо
хорошая автарка
k
так оно и есть но почему?
не знаю что у тебя там, ну кука может экспайрится потому, что время вышло (неожиданно)
ты в курсе как сессии работают приблизительно в пхп? Если нет - рекомендую ознакомиться
ты в курсе как сессии работают приблизительно в пхп? Если нет - рекомендую ознакомиться
Л
Можете-ли вы представить такую себе ситуацию.
Допустим есть некая система А.
Она может инициировать некоторую сущность... И присвоить ей инкрементальный id.
Эта система уже была связана с некоторой системой С, и они синхронно обмениваются изменениями по сущностям этого типа, в системе С им присваивается так-же UUID, а инкрементальной id из системы А сохраняется в поле.
Теперь вы добавляете к ним новую систему Б. Отличие её от Е в том, что она тоже может инициировать сущности, и вы решаете для этого в ней тоже использовать инкрементальный id. Сущность из этой системы "уходит" для обмена информацией в систему А не сразу. В систему Е она вовсе не уходит, т.к. в неё она уже поступает из А.
И вот, теперь вы должны получить обратно сообщения о том, что система А и Е получили вашу инициированную в Б сущность, а так-же дополненные ими данные. Чтобы вы могли и дальше обмениваться информацией по этой сущности между системами А и Б, так-что теперь вы добавляете поле "инкрементальный id из системы Б" в сущности в системах А и Е (чтобы они обе могли отправить обновления по сущности в систему Б).
И так вопрос, почему вы не хотите начать использовать один общий uuid?
Две из трех систем на пхп так-что вопрос релейтед.
Допустим есть некая система А.
Она может инициировать некоторую сущность... И присвоить ей инкрементальный id.
Эта система уже была связана с некоторой системой С, и они синхронно обмениваются изменениями по сущностям этого типа, в системе С им присваивается так-же UUID, а инкрементальной id из системы А сохраняется в поле.
Теперь вы добавляете к ним новую систему Б. Отличие её от Е в том, что она тоже может инициировать сущности, и вы решаете для этого в ней тоже использовать инкрементальный id. Сущность из этой системы "уходит" для обмена информацией в систему А не сразу. В систему Е она вовсе не уходит, т.к. в неё она уже поступает из А.
И вот, теперь вы должны получить обратно сообщения о том, что система А и Е получили вашу инициированную в Б сущность, а так-же дополненные ими данные. Чтобы вы могли и дальше обмениваться информацией по этой сущности между системами А и Б, так-что теперь вы добавляете поле "инкрементальный id из системы Б" в сущности в системах А и Е (чтобы они обе могли отправить обновления по сущности в систему Б).
И так вопрос, почему вы не хотите начать использовать один общий uuid?
Две из трех систем на пхп так-что вопрос релейтед.
k
Лев
Можете-ли вы представить такую себе ситуацию.
Допустим есть некая система А.
Она может инициировать некоторую сущность... И присвоить ей инкрементальный id.
Эта система уже была связана с некоторой системой С, и они синхронно обмениваются изменениями по сущностям этого типа, в системе С им присваивается так-же UUID, а инкрементальной id из системы А сохраняется в поле.
Теперь вы добавляете к ним новую систему Б. Отличие её от Е в том, что она тоже может инициировать сущности, и вы решаете для этого в ней тоже использовать инкрементальный id. Сущность из этой системы "уходит" для обмена информацией в систему А не сразу. В систему Е она вовсе не уходит, т.к. в неё она уже поступает из А.
И вот, теперь вы должны получить обратно сообщения о том, что система А и Е получили вашу инициированную в Б сущность, а так-же дополненные ими данные. Чтобы вы могли и дальше обмениваться информацией по этой сущности между системами А и Б, так-что теперь вы добавляете поле "инкрементальный id из системы Б" в сущности в системах А и Е (чтобы они обе могли отправить обновления по сущности в систему Б).
И так вопрос, почему вы не хотите начать использовать один общий uuid?
Две из трех систем на пхп так-что вопрос релейтед.
Допустим есть некая система А.
Она может инициировать некоторую сущность... И присвоить ей инкрементальный id.
Эта система уже была связана с некоторой системой С, и они синхронно обмениваются изменениями по сущностям этого типа, в системе С им присваивается так-же UUID, а инкрементальной id из системы А сохраняется в поле.
Теперь вы добавляете к ним новую систему Б. Отличие её от Е в том, что она тоже может инициировать сущности, и вы решаете для этого в ней тоже использовать инкрементальный id. Сущность из этой системы "уходит" для обмена информацией в систему А не сразу. В систему Е она вовсе не уходит, т.к. в неё она уже поступает из А.
И вот, теперь вы должны получить обратно сообщения о том, что система А и Е получили вашу инициированную в Б сущность, а так-же дополненные ими данные. Чтобы вы могли и дальше обмениваться информацией по этой сущности между системами А и Б, так-что теперь вы добавляете поле "инкрементальный id из системы Б" в сущности в системах А и Е (чтобы они обе могли отправить обновления по сущности в систему Б).
И так вопрос, почему вы не хотите начать использовать один общий uuid?
Две из трех систем на пхп так-что вопрос релейтед.
не знаю почему я не хочу начать использоваться один общий uuid(а я не хочу? 🤔), но мне понравился в вопросе переход от системы А к системе С (минуя Б) и ссылка на систему Е до того, как эта система (Е) была упомянута :D
DE
Лев
Можете-ли вы представить такую себе ситуацию.
Допустим есть некая система А.
Она может инициировать некоторую сущность... И присвоить ей инкрементальный id.
Эта система уже была связана с некоторой системой С, и они синхронно обмениваются изменениями по сущностям этого типа, в системе С им присваивается так-же UUID, а инкрементальной id из системы А сохраняется в поле.
Теперь вы добавляете к ним новую систему Б. Отличие её от Е в том, что она тоже может инициировать сущности, и вы решаете для этого в ней тоже использовать инкрементальный id. Сущность из этой системы "уходит" для обмена информацией в систему А не сразу. В систему Е она вовсе не уходит, т.к. в неё она уже поступает из А.
И вот, теперь вы должны получить обратно сообщения о том, что система А и Е получили вашу инициированную в Б сущность, а так-же дополненные ими данные. Чтобы вы могли и дальше обмениваться информацией по этой сущности между системами А и Б, так-что теперь вы добавляете поле "инкрементальный id из системы Б" в сущности в системах А и Е (чтобы они обе могли отправить обновления по сущности в систему Б).
И так вопрос, почему вы не хотите начать использовать один общий uuid?
Две из трех систем на пхп так-что вопрос релейтед.
Допустим есть некая система А.
Она может инициировать некоторую сущность... И присвоить ей инкрементальный id.
Эта система уже была связана с некоторой системой С, и они синхронно обмениваются изменениями по сущностям этого типа, в системе С им присваивается так-же UUID, а инкрементальной id из системы А сохраняется в поле.
Теперь вы добавляете к ним новую систему Б. Отличие её от Е в том, что она тоже может инициировать сущности, и вы решаете для этого в ней тоже использовать инкрементальный id. Сущность из этой системы "уходит" для обмена информацией в систему А не сразу. В систему Е она вовсе не уходит, т.к. в неё она уже поступает из А.
И вот, теперь вы должны получить обратно сообщения о том, что система А и Е получили вашу инициированную в Б сущность, а так-же дополненные ими данные. Чтобы вы могли и дальше обмениваться информацией по этой сущности между системами А и Б, так-что теперь вы добавляете поле "инкрементальный id из системы Б" в сущности в системах А и Е (чтобы они обе могли отправить обновления по сущности в систему Б).
И так вопрос, почему вы не хотите начать использовать один общий uuid?
Две из трех систем на пхп так-что вопрос релейтед.
Хочу и буду использовать UUID. Не вопрос.
Р
Используй uuid и не парься, аналогичная ситуация только третья система - 1с, оттуда забираем guid, у меня генерируем свои uuid, все отлично синхранизируется
Л
Я тоже хочу uuid, но мне нужно применить некую форму реверсивной психологии...
Л
Чтобы понять почему этого не хотят некоторые другие агенты. И соответственно вычислить аргументы которые их убедят.
Л
Это лишь зарисовка, в реальности уже есть система Д в которой в своё время так-же встал этот вопрос и там так-же не стали использовать uuid, просто пока они с Б не пересекаются в плане сущностей с которыми работают.
Л
Но в следующем этапе этой эпической интеграции пересекутся, и по текущей логике работы сущности будут уже снабжены либо 4 разными id, либо будет разработана нетривиальная система обмена.
Л
Руслан
Используй uuid и не парься, аналогичная ситуация только третья система - 1с, оттуда забираем guid, у меня генерируем свои uuid, все отлично синхранизируется
Система Е из анекдота - это как раз 1с...
АЯ
Лев
Чтобы понять почему этого не хотят некоторые другие агенты. И соответственно вычислить аргументы которые их убедят.
потому что мускуль старый не умеет в уид, только в строки. а строки на больших объёмах работают медленнее чем инты.
всё.
минусов у автоинкремента (как по мне) намного больше чем плюсов.
всё.
минусов у автоинкремента (как по мне) намного больше чем плюсов.
VT
потому что мускуль старый не умеет в уид, только в строки. а строки на больших объёмах работают медленнее чем инты.
всё.
минусов у автоинкремента (как по мне) намного больше чем плюсов.
всё.
минусов у автоинкремента (как по мне) намного больше чем плюсов.
юид это всё еще большое число по сути своей.
если уж очень хочется, можно на входе\выходе с базы конвертер какой повесить и забить.
если уж очень хочется, можно на входе\выходе с базы конвертер какой повесить и забить.