Anton
C# guru на любой непонятный стактрейс: “не баг, а фича”
Pawel
Кто нибудь юзает orm-ку reform?
Dmitriy
Кто нибудь юзает orm-ку reform?
тут в чате есть автор, можно попробовать минуя посредников адресовать вопрос ему напрямую
Pawel
тут в чате есть автор, можно попробовать минуя посредников адресовать вопрос ему напрямую
вы бы ник автора написали
Илья
@alek_si
Илья
Алексей, тут вопрос по reform :)
Alexey
Автор болеет и может тупить
Pawel
))
Roman
О! https://www.youtube.com/watch?v=rWJHbh6qO_Y
Фитцпатрик говорит, что мы не будем убивать уже существующий код - it always will be usable. Типа, код из Go1 будет продолжать нормально комплироваться в Go2
что значит что обратная совместимость не сломается..
Alexey
Так а где вопрос?
Alexey
Нет
Pawel
ок, спасибо)
Aleksandr
статистика "багов"
слово "фича" не синоним и не антоним слова "баг". Я искренне не понимаю
Artuchka
слово "фича" не синоним и не антоним слова "баг". Я искренне не понимаю
я понимаю, но ради рофла всё-таки можно приравнять эти два значения, т.к. иногда они именно в таком смысле употребляются
Aleksandr
мде.
Aleksandr
я вот иногда наблюдаю как люди месяцами молчат в чате, а потом свое первое сообщение тратят вот на это
Aleksandr
и думаешь: вот реально ты так хотел вступить в наше сообщество - через лол, школоло и рофл?
Roman
затем, что любая известная нам модель хорошо эмулируется в реляционной
эмулируется - да, хорошо - нет)
графы более реляционны чем реляционки, relational DBMS это просто историческое название, не было тогда ещё достойных графовых БД
дело не только в index-free-adjacency, дело скорее в языке запросов и тут SQL просто позорится со своими JOIN'ами
Daniel
rdbms захватили мир потому, что любая другая структура эмулируется на них успешно
Roman
rdbms захватили мир потому, что любая другая структура эмулируется на них успешно
а мне кажетсячто причина тому более низкий уровень абстракции. Написать толковую графовую БД сложнее, чем табличную. Вот так и вышло, что первые реляционки были табличными и SQL стал их стандартом, но это уже неактуально ибо мы не стоит на месте и начинается эра графовых
Daniel
в каком смысле она начинается?
Daniel
что у нас готово к промышленному оспользованию?
Roman
в каком смысле она начинается?
в том что появляются наконец более толковые решения, которых раньше не было
Roman
что у нас готово к промышленному оспользованию?
зависит от конкретной задачи, я в принципе Arango рекомендую, Neo так себе, ещё есть Janus-Graph но они далеки ещё от промышленного использования, документация сыра
Roman
я бы не называл классический SQL - реляционным, я бы называл его истинным названием: табличный
Daniel
в том. что ты называешь "классическим sql" есть встроенные средства поддержания консистентности наборов данных: foreign keys
Daniel
поэтому они все же реляционные
Roman
в том. что ты называешь "классическим sql" есть встроенные средства поддержания консистентности наборов данных: foreign keys
foreign keys работают хуже с реляционными данными нежели графы с index-free-adjacency по крайней мере в теории (практика зависит от конкретной технической реализации графовой бд)
Daniel
что такое "хуже"?
Daniel
разложить набор данных в нормализованную структуру я могу школьников научить
Daniel
с графовыми это далеко не так
Roman
что такое "хуже"?
в графе у тебя, очень грубо выражаясь, "указатели" на узлы, а не индексы.
"указатели" работают шустрее индексов
Daniel
медленее
https://www.arangodb.com/2018/02/nosql-performance-benchmark-2018-mongodb-postgresql-orientdb-neo4j-arangodb/
если я правильно читаю легенду - пострес абсолютный победитель
Pawel
с графовыми это далеко не так
В orientdb спокойно ложатся объекты джавы ( и голанга) без всяких орм и без потери консистентности
Roman
разложить набор данных в нормализованную структуру я могу школьников научить
я не спорю о том что табличные бд имеют смысл в тех или иных случаях, но большинство задач таки проще решаются графом нежели таблицей. Причина: язык запросов. SQL JOIN'ы это кошмар для чуть более сложных запросов
Roman
https://www.arangodb.com/2018/02/nosql-performance-benchmark-2018-mongodb-postgresql-orientdb-neo4j-arangodb/
если я правильно читаю легенду - пострес абсолютный победитель
с чего такой вывод?)) он по большей степени медленее Arango (single read, single write, write sync, shortest path, neighbors, neighbors of neighbors, aggregation)
только памяти меньше жрёт
Anonymous
Всем привет!
Разбираюсь с Sentry
Беру пример из документации
func main() {
raven.SetDSN("myDSN") // скопировал из Sentry
_, err := os.Open("filename.ext")
if err != nil {
raven.CaptureErrorAndWait(err, nil)
log.Panic(err)
}
}
и ничего не приходит в sentry
почему?(
Roman
В orientdb спокойно ложатся объекты джавы ( и голанга) без всяких орм и без потери консистентности
ориент херово оптимизирован, поэтому его с реляционными сложно сравнивать, он тупо нагрузку не держит
Roman
не только
в любом случае Postgres там далеко не абсолютный победитель а скорее терпит поражение
Pavel
Всем привет!
Разбираюсь с Sentry
Беру пример из документации
func main() {
raven.SetDSN("myDSN") // скопировал из Sentry
_, err := os.Open("filename.ext")
if err != nil {
raven.CaptureErrorAndWait(err, nil)
log.Panic(err)
}
}
и ничего не приходит в sentry
почему?(
привет! не знаю у меня норм работает. 🙈
Roman
я не могу 100% быть уверенным в том что бенчмарк не biased потому-что таки сии числа это маркетинг Arango, но врать они тоже не будут
DMITRY
видел orientDB в продакшене
DMITRY
нагрузку реально не держит
DMITRY
производительность настолько печальная,что на него делали кеширование в Solr
Илья
тогда смотри discarded в sentry
Илья
тк функция синхронная, и со стороны приложения пуля, скорее всего, вылетела
l3xxxy
Roman
arangodb она бесплатная?
коммьюнити версия имеется как у любого современного open source проекта
https://www.arangodb.com/subscriptions/
ᛃᛟᚺᚾ ᚠᚨcᛖᛚᛖᛊᛊ ᛞᛟᛖ
foreign keys работают хуже с реляционными данными нежели графы с index-free-adjacency по крайней мере в теории (практика зависит от конкретной технической реализации графовой бд)
причем здесь как оно работает? есть реляционная алгебра, она идеально ложится в то что ты называешь "табличные базы данных"
Roman
причем здесь как оно работает? есть реляционная алгебра, она идеально ложится в то что ты называешь "табличные базы данных"
я лишь утвердил что графы более "реляционны" нежели табличные SQL RDBMS ибо более оптимизированы под взаимосвязи узлов и легче в работе с ними
ᛃᛟᚺᚾ ᚠᚨcᛖᛚᛖᛊᛊ ᛞᛟᛖ
я лишь утвердил что графы более "реляционны" нежели табличные SQL RDBMS ибо более оптимизированы под взаимосвязи узлов и легче в работе с ними
ну ты можешь называть их как хочешь, конечно же, только они от этого реляционными не станут. определенные виды баз данных поэтому собственно и называются реляционными, потому что реализуют реляционную алгебру. графы не реализуют. в этом то и фокус. но это не делает, один или другой вид хуже.
ᛃᛟᚺᚾ ᚠᚨcᛖᛚᛖᛊᛊ ᛞᛟᛖ
но это вообще офтоп, сорри
Roman
ну ты можешь называть их как хочешь, конечно же, только они от этого реляционными не станут. определенные виды баз данных поэтому собственно и называются реляционными, потому что реализуют реляционную алгебру. графы не реализуют. в этом то и фокус. но это не делает, один или другой вид хуже.
что это означает на практике? что я не смогу сделать в графе что смогу сделать в SQL?
Илья
Вообще пусто все там(((
значит проблема в руках, вот взял создал все это, добавил в init устанвку sdn и плюнул ошибку, она на месте
qurabay
How to use template?
Roman
ну ты можешь называть их как хочешь, конечно же, только они от этого реляционными не станут. определенные виды баз данных поэтому собственно и называются реляционными, потому что реализуют реляционную алгебру. графы не реализуют. в этом то и фокус. но это не делает, один или другой вид хуже.
наивно предположу, что умные дядки в IBM во времена зарождения тематики баз данных определили что "relational" это "SQL + tables"
хотя с чисто логической точки зрения "relational" от слова "relation" это моделирование взаимосвязей сущностей, и с этим графы и графовые языки запросов справляются гораздо лучше нежели таблицы и SQL.
Это и является причиной того, что я отказываюсь применять классическую терминологию "реляционных бд", потому-что этот термин, по моему мнению, уже неактуален, ибо "classical RDBMS" это по факту "SQL + tables".
Dmitriy / დიმიტრი
Коллеги.
Используем в качестве БД MySQL 8. В качестве ORM используем GORM.
В схеме БД некоторые поля из себя представляют UUID'ы и что бы правильно их получить/отправить в MySQL приходится писать чистым SQL'ем вот такое:
INSERT INTO bookmark
(publication_id, user_id, created_at, updated_at)
VALUES
(?, UUID_TO_BIN(?), ?, ?)
Вопрос: можно ли как-то обойтись без UUID_TO_BIN не меняя схему? Может есть какие-то обертки/типы которые преобразуют uuid в MySQL-формат и обратно?
Nikita
Коллеги.
Используем в качестве БД MySQL 8. В качестве ORM используем GORM.
В схеме БД некоторые поля из себя представляют UUID'ы и что бы правильно их получить/отправить в MySQL приходится писать чистым SQL'ем вот такое:
INSERT INTO bookmark
(publication_id, user_id, created_at, updated_at)
VALUES
(?, UUID_TO_BIN(?), ?, ?)
Вопрос: можно ли как-то обойтись без UUID_TO_BIN не меняя схему? Может есть какие-то обертки/типы которые преобразуют uuid в MySQL-формат и обратно?
нагуглил такое
https://github.com/jinzhu/gorm/issues/1668
Юзается "github.com/satori/go.uuid"
Pawel
Pawel
Господа кто в sqlite умеет.
Хочу писать в базу одновременно из двух процессов.
Для этого поставил как рекомендовано - journal=WAL cache=shared.
Вопрос - этого достаточно, или ньюансы есть?