типа указать типы для полей?

не уверен, и, думаю, что вы, батенька, делаете что-то не то

да вроде все то, у меня в $test['DATE_UPDATE'] лежит обьект класса Test.

а я о том, что хранить в массиве разные объекты - это путь к боли

я бы ещё казнил за ключи в верхнем регистре, но это вкусовщина)

да вроде все то, у меня в $test['DATE_UPDATE'] лежит обьект класса Test.

С - семантика!)

а я о том, что хранить в массиве разные объекты - это путь к боли

да это битрикс :C

да это битрикс :C

а, то есть, боль уже пришла сама

а, то есть, боль уже пришла сама

ага(

/** @var array<string, SomeObject> $array */ $array = [/** .... */]; /** @var SomeObject|null $object */ $object = $array['someKey'] ?? null;

шторм умеет в дженерики по тайпхинтам?

неа

люди умеют) иногда

чёт битрикс никому из знакомых разработчиков не вкатывает.

чёт битрикс никому из знакомых разработчиков не вкатывает.

за упоминание битрикса просто в рожу бьют

шторм умеет в дженерики по тайпхинтам?

омг

омг

что тебя смущает?)

ну я потому и упомянул 1. шторм 2. пхпдок

ну я потому и упомянул 1. шторм 2. пхпдок

и имел ввиду только то, что шторм подсвечивал бы (возможные) места нарушений и выводил типы, попадающие в массив

за упоминание битрикса просто в рожу бьют

на битриксе тоже люди кодят)

на битриксе тоже люди кодят)

ага

"я не сам, меня заставили"..)

"я не сам, меня заставили"..)

Примерно так =)

ага

Страдают... и кодят -_-

В шторме, такое: /* @var App\Test $test['DATE_UPDATE'] */ $test['DATE_UPDATE']->... не работает для массивов?

есть плагин, deep-assoc-completion. может поможет

есть плагин, deep-assoc-completion. может поможет

Спасибо

шутки за 300

шторм умеет в дженерики по тайпхинтам?

не, он union types как пересечение типов делает для комплита (Users[]|ArrayCollection). Я у чела из джетбрэйнс спрашивал не планируют ли, а он рассказал душещипательную историю о том как плохо у них написан парсер и что они пару раз пробовали его переписать и пришлось откатывать ибо у корпоративных клиентов ломалось.

но в теории это можно сделать плагином (правда свой phpdoc парсер нужен)

такое знаю

чёта вумная (или нет?) мюсль появилась. Про всякое время в объектах (напр. время создания, изменения ... ). Что не стоит это доверять БД. Потому-что во-первых непонятно когда объект будет сохранён и время между его созданием и сохранением может быть каким угодно (мало ли где он там болтаться будет). А во-вторых (или даже во-первых) даты могут понадобиться до сохранения.

базе такое ненадо делать!

Хотя если эта дата отражает именно время записи в БД, то можно

Ещё неясно какой часовой пояс на сервере с БД выставлен

Ещё неясно какой часовой пояс на сервере с БД выставлен

UTC

Ещё неясно какой часовой пояс на сервере с БД выставлен

ну это уже чисто технический момент по-моему

чёта вумная (или нет?) мюсль появилась. Про всякое время в объектах (напр. время создания, изменения ... ). Что не стоит это доверять БД. Потому-что во-первых непонятно когда объект будет сохранён и время между его созданием и сохранением может быть каким угодно (мало ли где он там болтаться будет). А во-вторых (или даже во-первых) даты могут понадобиться до сохранения.

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

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

да, я собственно думал про идентификацию сущностей и отсюда переполз на даты

смотри типичный кейс: пишем в таблицу insert into tbl set create_at=now() и настроена реgлика на другой сервер .. (дублируются инсерты апдейты и делеты) и вдруг реплика чуток отстала.... на той стороне NOW() станет совсем другим ...

смотри типичный кейс: пишем в таблицу insert into tbl set create_at=now() и настроена реgлика на другой сервер .. (дублируются инсерты апдейты и делеты) и вдруг реплика чуток отстала.... на той стороне NOW() станет совсем другим ...

в любом случае будет другим)

вотвот

смотри типичный кейс: пишем в таблицу insert into tbl set create_at=now() и настроена реgлика на другой сервер .. (дублируются инсерты апдейты и делеты) и вдруг реплика чуток отстала.... на той стороне NOW() станет совсем другим ...

хороший пример

смотри типичный кейс: пишем в таблицу insert into tbl set create_at=now() и настроена реgлика на другой сервер .. (дублируются инсерты апдейты и делеты) и вдруг реплика чуток отстала.... на той стороне NOW() станет совсем другим ...

да, для логической репликации это фатально)

да, для логической репликации это фатально)

да .всегда забываю как она зовется

Поэтому все параметры лучше вынести на приложение) если конечно не row based репликация (со своими проблемами)

Есть ли у кого варианты такого https://github.com/aarondfrancis/URLcrypt но без mcrypt_encrypt под капотом?

Есть ли у кого варианты такого https://github.com/aarondfrancis/URLcrypt но без mcrypt_encrypt под капотом?

https://gist.github.com/fesor/984f2112ebf2e868c2dd877dce97b62a

просто добавь сверху urlencode

Ок, попробую сейчас. Спасибо

ERROR: S client not available

ну или юзай что-то свое (base62) вместо base64.

имплементацию base62 какую можешь стянуть с либок которые UUID энкодят в короткую запись

Там просто от любопытных глаз нежели что-то дико секъюрное

Там просто от любопытных глаз нежели что-то дико секъюрное

а ну тогда можешь просто в base64 без шифрований всяких

хз

Да, понял, спасибо

ну или юзай что-то свое (base62) вместо base64.

чтобы сложнее догадаться было?

чтобы сложнее догадаться было?

не, если оно в урле то base64+urlencode выходит длиннее в количестве символов чем base62

base64 оно не для секьюрности а что бы бинарные данные можно было безопасно текстом передавать

секьюрность это AES

ну это да, я знаю я имел ввиду, что про base64 знают точно больше "левых" чуваков, нежели чем про base62

Пока одним их простых вариантов видится использовать https://github.com/ivanakimov/hashids.php Т.к. "прятать" надо числовое значение, надеюсь, что не возникнет запроса на большее со строками...

граждане

а норм ли тема переопределять конструктор у Exception

http://php.net/manual/en/language.exceptions.extending.php

ясно, спасибо

а норм ли тема переопределять конструктор у Exception

Можно просто забубенить свой именованный

а норм ли тема переопределять конструктор у Exception

норм

Можно просто забубенить свой именованный

зачем?

не ну это всегда лучше чем new но все ж)

не ну это всегда лучше чем new но все ж)

Что бы добавить семантики, понятнее будет

не ну это всегда лучше чем new но все ж)

а почему всегда лучше? семантика или еще профиты?

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

минусов как бы нет особо