Только админы могут пинить сообщения? Дайджест потерялся.

заново сделаю че

https://habrahabr.ru/company/zfort/blog/346642/

https://habrahabr.ru/users/pronskiy/

ты можешь просто подписаться на чувака)

в том числе и на твиттер

/link@yetanotherstatsbot

https://b.yasb.exileed.com/telegram/chat/1001042383571

какой тулзой(краулером?) можно пройти по всем урлам на сайте, чтобы отыскать потенциальные 500е ?

wget

ага, рекурсивным вгетом. Просто думал, может для тестировщиков есть какие-то такие тулзы уже готовые с красивым отчётом в экселе и тп :)

Сами напишут) не биг дил)

ага, рекурсивным вгетом. Просто думал, может для тестировщиков есть какие-то такие тулзы уже готовые с красивым отчётом в экселе и тп :)

есть такие

но будет работать только для публичных ссылок

сам понимаешь)

какой тулзой(краулером?) можно пройти по всем урлам на сайте, чтобы отыскать потенциальные 500е ?

гугл :)

https://www.npmjs.com/package/js-crawler

вот можешь этим попробовать потестить

там есть хуки, так что "в теории" можно и авторизацию захэндлить

но полностью автоматом пожалуй только что-то простое выйдет

пока остановился на этом варианте https://wummel.github.io/linkchecker/ если не зайдёт, то придётся самому что-то костылить

спасибо?

Провайдер vps пишет что они переходят на другие сервера, на более крутые с новыми плюшками и за ту же цену и предлогают перенести или пересоздать серв. В случае переноса данных они мне создадут мою эко систему с настройками fail2ban letsencrypt SSL nginx apache php mysql и прочее чтобы все так же взаимодействовало по типу как у образов wmvare, но как я понял там разные системы виртуализации

Привет, кто работал с eav model, какие есть "за" вместо того чтобы использовать no-sql решения? Для примера давайте возьмём авито, каждое объявление в зависимости от категории имеет разный набор свойств, если бы я писал клон, то мне видится решение в eav model + single table inheritance. Но это белый взгляд чисто "пальцем в небо". Может у кого есть юз кейсы, делитесь. Из преимуществ eav model: × Динамические свойства сущности (ещё бы, это основная цель). × Остаёмся в реляционной модели, не плодим технологии. Недостатки : × В случае необходимости "сырой" записи (например импорт товаров из csv) без использования обёртки придётся поплясать с бубном над конвертером. × Без кеша запросы довольно тяжёлые(я про выборку по значениям атрибутов). × Потенциальные проблемы на хайлоаде(я не спец в хайлоаде, но думаю имеет место быть проблемам с партиционированием). × Порог входа выше. Альтернативы: × Eav "на запись", elasticsearch "на чтение". × No-sql хранилища, например mongodb. × Использовать json типы, например jsonb для postgres

Привет, кто работал с eav model, какие есть "за" вместо того чтобы использовать no-sql решения? Для примера давайте возьмём авито, каждое объявление в зависимости от категории имеет разный набор свойств, если бы я писал клон, то мне видится решение в eav model + single table inheritance. Но это белый взгляд чисто "пальцем в небо". Может у кого есть юз кейсы, делитесь. Из преимуществ eav model: × Динамические свойства сущности (ещё бы, это основная цель). × Остаёмся в реляционной модели, не плодим технологии. Недостатки : × В случае необходимости "сырой" записи (например импорт товаров из csv) без использования обёртки придётся поплясать с бубном над конвертером. × Без кеша запросы довольно тяжёлые(я про выборку по значениям атрибутов). × Потенциальные проблемы на хайлоаде(я не спец в хайлоаде, но думаю имеет место быть проблемам с партиционированием). × Порог входа выше. Альтернативы: × Eav "на запись", elasticsearch "на чтение". × No-sql хранилища, например mongodb. × Использовать json типы, например jsonb для postgres

почему реляционная модель у тебя в плюсах?

> Использовать json типы, например jsonb для postgres все сильно упирается в то, что требуется от данных

почему реляционная модель у тебя в плюсах?

Контроль целостности, ACID.

Контроль целостности, ACID.

контроль целостности = схема. У тебя схема по определению отсутствует.

в документноориентированных как раз таки схему ты можешь определить

ACID - если ты изменяешь один документ - у тебя это изменение атомарно

eav на большом объёме данных всё равно сведётся к созданию представлений и запихиванию их в тот же nosql

то есть все преимущества реляционки у тебя сводятся к неумению работать с другими представлениями данных на запись))

это не то что бы плохо - надо работать с тем что умеешь готовить

но.... это не значит что это плюс

eav на большом объёме данных всё равно сведётся к созданию представлений и запихиванию их в тот же nosql

В том и вопрос, стоит ли изначально выбирать eav model если на горизонте видны эти проблемы. Покрывают ли на практике плюсы все минусы.

В том и вопрос, стоит ли изначально выбирать eav model если на горизонте видны эти проблемы. Покрывают ли на практике плюсы все минусы.

ну тут вопрос в другом: а что есть большой объём?

сам по себе еав живёт, работает...) и вполне успешно временами

то есть все преимущества реляционки у тебя сводятся к неумению работать с другими представлениями данных на запись))

Мне кажется ответ где-то близко...

В том и вопрос, стоит ли изначально выбирать eav model если на горизонте видны эти проблемы. Покрывают ли на практике плюсы все минусы.

как по мне EAV сложно и не нужно

лет 10 назад выбора особо небыло

сейчас есть

мне тут очень рекламировали для подобного orientdb

гибрид графовой и документноориентированной базы

это не то что бы плохо - надо работать с тем что умеешь готовить

Ну я по сути спрашиваю рецепт у тех, кто пробовал различные подходы. Как-то приходилось давно работать с ЕАВ, помню что больно было из-за того что документ по сути разбит был на мелкие сущности.

Ну я по сути спрашиваю рецепт у тех, кто пробовал различные подходы. Как-то приходилось давно работать с ЕАВ, помню что больно было из-за того что документ по сути разбит был на мелкие сущности.

ну я и говорю - весь вопрос в том, что ты планируешь с данными делать

документная модель для этого удобнее но легко накосячить с тем как ты все приготовишь

вот штуки типа orientdb предлагают определенный компромис в подходах (связи)

ну я и говорю - весь вопрос в том, что ты планируешь с данными делать

Хорошо, можешь подсказать для каких юзкейсов ЕАВ нужен?

Хорошо, можешь подсказать для каких юзкейсов ЕАВ нужен?

с тех пор как постгри умеют jsonb - ни для каких

(ну и мускуль)

дальше весь вопрос в том, хватит ли тебе jsonb или у тебя более сложные запросы

ну и еще могут быть всякие мелкие требования по связанным значениям и т.д.

с тех пор как постгри умеют jsonb - ни для каких

Окей, соглашусь, jsonb хорошая альтернатива ЕАВ. Просто один раз неправильно его приготовил и не понравилось.

дальше весь вопрос в том, хватит ли тебе jsonb или у тебя более сложные запросы

Как раз таки из-за выборок не понравился, я тогда в elasticsearch не умел.

Как раз таки из-за выборок не понравился, я тогда в elasticsearch не умел.

ты о фильтрации?

p.s. я не знаю как в mysql а в постгрессе с этим все отлично

а в мускуле jsonb разве есть?

когда в последний раз его трогал, не было

в 5.7 вроде бы появился

но хз как оно, не юзаю

https://www.arangodb.com/

http://orientdb.com/orientdb/

вот еще наброшу варианты для поковырять вечерком

привет. Мне тут проект с yii migrator попал. Задача изменить тип столбца в постгресе, в ней уже есть данные. Можно в нем как-то взять, данные, изменить столбец, вставить данные? Чтоб одной миграцией и без дополнительных столбцов

ALTER TABLE nnn ALTER COLUMN xxx TYPE newtype USING expression

ERROR: S client not available

expression - выражение что тебе делать с данными старого столбца, что бы получился тип нового

ты о фильтрации?

Да там много ошибок сделал. Фильтрации все же заставляли jsonb операторы использовать, что заставило писать сырых запросов, а в эластик я тогда не умел.

Да там много ошибок сделал. Фильтрации все же заставляли jsonb операторы использовать, что заставило писать сырых запросов, а в эластик я тогда не умел.

ну то есть... ты считаешь что сырые запросы в постгрю это хуже сырых запросов в эластику?)

ну то есть... ты считаешь что сырые запросы в постгрю это хуже сырых запросов в эластику?)

Хм... Нет, не считаю. В фреймворке что использую на повседнев для работы с бд используется паттерн ActiveRecord и для поиска по jsonb приходилось скоупы городить. Это не так плохо, но увеличивает порог входа следующего разработчика. В случае с эластиком есть хорошая обьектная обёртка с приятным быстровникаемым апи.

Хм... Нет, не считаю. В фреймворке что использую на повседнев для работы с бд используется паттерн ActiveRecord и для поиска по jsonb приходилось скоупы городить. Это не так плохо, но увеличивает порог входа следующего разработчика. В случае с эластиком есть хорошая обьектная обёртка с приятным быстровникаемым апи.

звучит этот довод примерно так: Ты пойми, михалыч, у нас принято любые проблемы решать при помощи молотка... а потому вместо отвертки я лучше дрель заюзаю.

> В случае с эластиком есть хорошая обьектная обёртка с приятным быстровникаемым апи. это потому что эластика юзает json в качетсве языка запросов

Хм... Нет, не считаю. В фреймворке что использую на повседнев для работы с бд используется паттерн ActiveRecord и для поиска по jsonb приходилось скоупы городить. Это не так плохо, но увеличивает порог входа следующего разработчика. В случае с эластиком есть хорошая обьектная обёртка с приятным быстровникаемым апи.

Это проститите какая есть хорошая "объектная" обертка над ElasticSearch?

ну то есть объектые обертки очень быстро становятся не такими удобными)

как только у тебя запросы начинают быть.... сложнее чем то что выдает тебе оператор ->> в постгре

Это проститите какая есть хорошая "объектная" обертка над ElasticSearch?

Только не говорите "Elastica" ... и так весь день подгорает

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

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

и не нужно писать километровых DSL поверх (котоыре всеравно рано или поздно тебя повдедут)

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

?

если кто-то думает что "объектная обертка" всегда все делает проще - увы и ах

Elastica - ок)

так же если мы будем всегда судить категориями "В фреймворке что использую на повседнев для работы с бд используется паттерн ActiveRecord " - то не стоит подпускать тогда таких людей к проектам где все "не так просто"

без активрекорда хайлодов бы не было)

самое смешное что выше идет рассуждение о плюсах и минусах подхода и при этом следом идет догматы

Я сегодня кресло прожигал: https://github.com/ruflin/Elastica/blob/master/lib/Elastica/Index.php#L196

без активрекорда хайлодов бы не было)

ты о том что из-за них приходится лишний десяток нод держать ;)

ты о том что из-за них приходится лишний десяток нод держать ;)

вроде того)

ну там оптимальное использование АР, все дела)

p.s. я доктриной обмазываюсь на полную что бы меня никто не обвинил в желании "пооптимизировать"

$index1 = $client->getIndex('aaa'); $index2 = $client->getIndex('bbbb'); $docs = $index1->search($query)->getDocuments(); $index2->deleteDocuments($docs); // Good debug bros! $client->updateDocuments($dosc);

ОО-design хуле

мутируй стэйт, испытывай сайд эффекты, грабь караваны

мутируй стэйт, испытывай сайд эффекты, грабь караваны

Серега, накинь с практики в чем могут быть косяки... Я сегодня доказать не смог (не желал)

Серега, накинь с практики в чем могут быть косяки... Я сегодня доказать не смог (не желал)

ммм косяки с действием на расстоянии?

Не оно понятно в моей голове

пусть почитают "GOTO considered harmful: retrospective"

там в целом неплохо об этом)