например как котлине

но оно уже есть и с type erasure

Роуз писал, что type erasure они сделали только для одной вещи - чтобы не было какого-то конкретного flag day, когда вся платформа должна встать и обновить свой код и бинарники с учётом того, что некоторые вещи стали generic

например как котлине

В котлине при этом нет вайлдкардов (и они вообще, кажется, плохо совмещаются с reified type parameters, по крайней мере, в реальном применении, но тут я могу ошибаться)

Это я не к тому, что Котлин плохой, а к тому, что надо сохранить обратную совместимость и всё такое

Это я не к тому, что Котлин плохой, а к тому, что надо сохранить обратную совместимость и всё такое

ну не на всю жизнь же )

В котлине при этом нет вайлдкардов (и они вообще, кажется, плохо совмещаются с reified type parameters, по крайней мере, в реальном применении, но тут я могу ошибаться)

в скале все чудесно совмещается хз как в котлине, в скале под "reified type param" имеется в виду наличие рядом (те имплиситно) спецобьекта, который знает все про оригинальный тип в рантайме

кстати, как в котлине сделано-то?

кстати, как в котлине сделано-то?

https://github.com/JetBrains/kotlin/blob/master/spec-docs/reified-type-parameters.md

https://github.com/JetBrains/kotlin/blob/master/spec-docs/reified-type-parameters.md

ну это спека, а как реализовано-то?

рефлексия в рантайме?

Это я не к тому, что Котлин плохой, а к тому, что надо сохранить обратную совместимость и всё такое

а как же SOLID? Open/closed principle: "software entities … should be open for extension, but closed for modification."

ну стала у тебя коллекция generic вместо legacy. Просто создай новый класс, назови ее по-другому

Кто нибудь знает, в мокито можно сделать verify не через VerificationMode, а просто по кол-ву вызовов? Ну т.е. не так verify(view, times(2)).doStaff() verifyNoMoreInteractions(view) а вот так verify(view).doStaff() verify(view).doStaff() verifyNoMoreInteractions(view)

InOrder order= inOrder(mock,mock,mock); order.verify(mock).doStuff() order.verify(mock).doStuff() не подойдет?

ну стала у тебя коллекция generic вместо legacy. Просто создай новый класс, назови ее по-другому

Кажется, придётся стандартную библиотеку дублировать сильно, что печально и неприятно

рефлексия в рантайме?

так вот же, написано: In inline functions, occurrences of a reified type parameter T are replaced with the actual type argument. просто добавляется Class<T> еще одним параметром

так вот же, написано: In inline functions, occurrences of a reified type parameter T are replaced with the actual type argument. просто добавляется Class<T> еще одним параметром

а для не inline?

или такого не может быть?

видимо это только для инлайн поддерживается

тогда странно, что с вайлдкардами не работает

оно ж на разных уровнях, реифайд в рантайме, вайлдкарды в компайлтайме

Мы говорим совсем о котлине?

Просто там есть, например, такой пример в доке inline fun <reified T> TreeNode.findParentOfType(): T? { var p = parent while (p != null && p !is T) { p = p.parent } return p as T? } И тут встаёт вопрос - как безболезненно и наиболее корректно сделать этот return, если у нас T может быть сложным вайлдкардом?

InOrder order= inOrder(mock,mock,mock); order.verify(mock).doStuff() order.verify(mock).doStuff() не подойдет?

Это вариант. Не очень удобно,но это уже что то, спасибо!

Господа, а в каком виде вы храните всякие пдфки для инвойсов/репортов и так далее? Как пдф? Или как темплейт + дата в бд + картинки отдельно?

Второе

а для не inline?

тлько для инлайн

Господа, а в каком виде вы храните всякие пдфки для инвойсов/репортов и так далее? Как пдф? Или как темплейт + дата в бд + картинки отдельно?

смотря какая бд! если реляционная то хорошо бинарные данные в ней вообще не держать

смотря какая бд! если реляционная то хорошо бинарные данные в ней вообще не держать

Пофиг же

Ну в смысле в любой бд держать бинари так себе идея.

cassandra?

смотря какая бд! если реляционная то хорошо бинарные данные в ней вообще не держать

Почему? А где держать тогда?

В самой базе держать бинари больно и слегка бессмысленно кмк, внешние ресурсы может?

Могу ошибаться, впрочем

Почему? А где держать тогда?

Бинари на файловом хранилище надо держать.

В кассандре можно Бинари держать

Все хорошо и есть хорошие кейсы

Бинари на файловом хранилище надо держать.

Ну а если эти бинари относятся как то с какой то сущностью?

Хранишь пути к ним

В базе

А сами бинари как данные тебе в реляционной базе бесполезны скорее всего же

Хранишь пути к ним

А если не одна машина?

Используйте Кассандру для бинарей

https://medium.com/walmartlabs/building-object-store-storing-images-in-cassandra-walmart-scale-a6b9c02af593

Все придумано до вас

А если не одна машина?

Все эти вопросы давно уже решены десятком способов, надо только выбрать подходящий в твоей ситуации

Все эти вопросы давно уже решены десятком способов, надо только выбрать подходящий в твоей ситуации

Это не ответ

Было предложено хранить файлы в файловой системе локальной и хранить путь

Ну мой вопрос резонный, а что делать если много данных

Было предложено хранить файлы в файловой системе локальной и хранить путь

Фоток например

Было предложено хранить файлы в файловой системе локальной и хранить путь

Окей, не локальной, храни произвольные системные идентификаторы (в зависимости от механизмов получения доступа), которые используются для получения доступа, это, поди, в любом случае не единственный файловый ресурс, к которому надо доступаться

Ну мой вопрос резонный, а что делать если много данных

Храни на сетевом хранилище. Или как сервис на хттп отдавай, если они клиентами идут наружу

Храни на сетевом хранилище. Или как сервис на хттп отдавай, если они клиентами идут наружу

Каком например сетевом хранилище?

Каком например сетевом хранилище?

Какое купишь, в таком и храни.

Опять уход от ответа

Ну чем плохо то хранить в Кассандре?

Опять уход от ответа

Нет, тупой ответ на тупой вопрос.

Опять уход от ответа

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

Нет, тупой ответ на тупой вопрос.

Вопрос не тупой, вполне резонный

Ну чем плохо то хранить в Кассандре?

Ты про Кассандру ничего не говорил

Сколько файлов, какой размер, сколько клиентов из читает и т.д. после этого уже можно что-то конкретное сказать.

Ты про Кассандру ничего не говорил

Ну так ты говорил что не стоит хранить в подобных хранилищах данные?

Пример с Кассандрой, кстати, описывает вполне конкретный, и, откровенно говоря, не самый распространённый кейс, потому что в 99 случаев из 100 ты не Волмарт

Сколько файлов, какой размер, сколько клиентов из читает и т.д. после этого уже можно что-то конкретное сказать.

Ну я конкретно же сказал, фотографии, могу уточнить от 10кб по 10 мб

А сами бинари как данные тебе в реляционной базе бесполезны скорее всего же

>в реляционной базе >кассандра

Ну я конкретно же сказал, фотографии, могу уточнить от 10кб по 10 мб

Это не конкретно.

Ну я конкретно же сказал, фотографии, могу уточнить от 10кб по 10 мб

Ты в состоянии прочитать сообщение, на которое отвечаешь?

если хранить в кассандре то привязан к кассандре если не в ней то не привязан

что не ясно то

у тебя кассандра это кластер из 3х серверов например

Ты в состоянии прочитать сообщение, на которое отвечаешь?

Да, но вопрос не очень корректно задан

значит картинки можно масштабировать на 3 сервера

Да, но вопрос не очень корректно задан

Корректнее, чем твои.

если хранить в кассандре то привязан к кассандре если не в ней то не привязан

Ага а если не в Кассандре то привязан к чему то другому, логично

к файловой системе

к ней все привязаны

ты можешь спокойно масштабировать картинки на 500 серверов и не возится с кассандрой

которая тебе на этих 500 серверах нафиг не нужна

Ну я конкретно же сказал, фотографии, могу уточнить от 10кб по 10 мб

Фотографии лучше как раз на диске хранить. Во первых nginx с диска из будет отдавать намного быстрее чем любая бд. Во вторых для создания миниатюри и прочих обработок меньше замочек с кодом.

Пример с Кассандрой, кстати, описывает вполне конкретный, и, откровенно говоря, не самый распространённый кейс, потому что в 99 случаев из 100 ты не Волмарт

Но оно работает хорошо

При любом количестве файлов

Плюс у тебя контроль того, что файл действительно есть хоть какой то

ты можешь спокойно масштабировать картинки на 500 серверов и не возится с кассандрой

С ней не нужно возиться

Но оно работает хорошо

Я не говорю, что решение плохое, да

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

что делать?

с url все более менее просто

Фотографии лучше как раз на диске хранить. Во первых nginx с диска из будет отдавать намного быстрее чем любая бд. Во вторых для создания миниатюри и прочих обработок меньше замочек с кодом.

Но это не масштабируется ,

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

То ты читаешь доку и делаешь

Как размещать Файлы Новым способом

С ней не нужно возиться

>Split up larger objects into smaller chunks and store them in different nodes of the Cassandra cluster Perform async parallel write of object chunks to several nodes at once speeding up the total write time taken Perform async parallel read of object chunks and do the aggregation at the application level Even better would be to directly stream the chunks in-order using transfer-encoding Chunked supported by Http protocol, thereby eliminating the need for the application to have anything in memory Это действительно не требует возни?

>Split up larger objects into smaller chunks and store them in different nodes of the Cassandra cluster Perform async parallel write of object chunks to several nodes at once speeding up the total write time taken Perform async parallel read of object chunks and do the aggregation at the application level Even better would be to directly stream the chunks in-order using transfer-encoding Chunked supported by Http protocol, thereby eliminating the need for the application to have anything in memory Это действительно не требует возни?

Нет

Потому что у тебя нет столько картинок

Как у волмарта

Кек