sqlite3 ?

типа того, но sqlite не умеет нужные мне индексы с кастомными выражениями.

ну можешь отдельное поле создать для сопоставлений, если производительност - узкое место

Решается созданием CI индекса.

Решается созданием CI индекса.

как вариант

?

Год назад сталкивался. Не помню ПГ или mysql. Там зависело поддерживает ли регистрозависомость файловая система или нет.

sqlite ещё и тормозной

ибо всё в тексте

я в итоге пользуюсь обычной таблицей с отключенным WAL

Год назад сталкивался. Не помню ПГ или mysql. Там зависело поддерживает ли регистрозависомость файловая система или нет.

скорее операционная система, а не файловая.

отсутствие unsigned long

короче у ПГ свои тараканы

Народ, что в Ди array operations ограничиваются одномерными массивами, это баг, или фича?

Народ, что в Ди array operations ограничиваются одномерными массивами, это баг, или фича?

фича, видимо есть еще ndslice, не оно?

сейчас гляну

ибо всё в тексте

нет же

я в итоге пользуюсь обычной таблицей с отключенным WAL

Точно! В норм RDBMS невозможно хранение только в памяти быстрое - репликации же ещё

фича, видимо есть еще ndslice, не оно?

Не, ну так я и стороннюю матрицу возьму, вместо своей.

Народ, что в Ди array operations ограничиваются одномерными массивами, это баг, или фича?

а массив массивов тебе никак?

Я про них и спрашиваю

c[][] = b[][] + a[][] не робыть

я не понял выражения, а компилятор тем более

c[] = b[] + a[] он понимает

хочется того же, но с перламутровыми пуговицами

c[][] = b + a?

int[3][3] ta,tb,tc; tc[][] = tb + ta; Error: invalid array operation tb + ta (possible missing [])

нет же

Окей. Меня ввели в заблуждение. Но часть правды там есть.

там проверки типов нет, может в этом смысле он не очень

Полез я Go снова смотреть. Не смотря на то что синтаксис по прежнему кажется отсталым, но понравилась идея с парсингом конфигов. Пологичнее чем в Ди сделано: var ( rootCommand = &cobra.Command{ Use: "etcd-dump-db", Short: "etcd-dump-db inspects etcd db files.", } listBucketCommand = &cobra.Command{ Use: "list-bucket [data dir or db file path]", Short: "bucket lists all buckets.", Run: listBucketCommandFunc, } )

вроде у нас так тоже можно?

ну оно чуточку менее читаемо выглядит

а в ди есть парсинг конфигов в фобосе чтоль?

да getopt

auto rslt = getopt(args, "foo|f", "Some information about foo.", &foo, "bar|b", "Some help message about bar.", &bar);

неплохо. кстати,а кто-нибудь cli писал на ди? типа своя строка приглашения и чтобы команды писать)

неплохо. кстати,а кто-нибудь cli писал на ди? типа своя строка приглашения и чтобы команды писать)

Вроде либы есть под это какие-то

Вроде либы есть под это какие-то

https://github.com/deviator/duseful/blob/master/manuals/desktop/readme.md#cli

Или я заблуждаюсь?

спасибо) полезные либы. вот dli прям близко то что хотел. посмотрю чего умеет.

а code.dlang.org у всех поломался?

и мою до кучи посмотреть можешь https://github.com/maxfreck/consoleur , если нужно организовать ввод в юниксовых терминалах с нормальным распознаванием CSI/SS3 последовательностей

Снова к теме про БД и ORM. Есть два подхода. Описать схему БД в коде и получить съему из самой БД. В чем минусы последнего подхода?

Вопрос - как организованы миграции. Всё остальное вторично.

Поясни плиз. Я миграции тока начал учиться писать

Где-то должно быть описание текущей версии схемы, по которому строятся скрипты обновления БД. Оно может быть в стиле ORM, а может и не быть. Имхо, брать схему из БД есть смысл, или когда это не наша БД, или когда мы не хотим светить схему.

и мою до кучи посмотреть можешь https://github.com/maxfreck/consoleur , если нужно организовать ввод в юниксовых терминалах с нормальным распознаванием CSI/SS3 последовательностей

погляжу, спасибо

Снова к теме про БД и ORM. Есть два подхода. Описать схему БД в коде и получить съему из самой БД. В чем минусы последнего подхода?

Нету второго подхода, как и ОРМ

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

Орм можно применять для вьюх верхнего уровня, мне кажется.

особо нет смысла

В мелких двузвенках.

Привязываться к гридам проще.

Да и формы автоматом можно генерировать.

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

В одном случае у меня вообще по текстовому описанию создаются модели орм и валидаторы импорта/экспорта в них.

Полез я Go снова смотреть. Не смотря на то что синтаксис по прежнему кажется отсталым, но понравилась идея с парсингом конфигов. Пологичнее чем в Ди сделано: var ( rootCommand = &cobra.Command{ Use: "etcd-dump-db", Short: "etcd-dump-db inspects etcd db files.", } listBucketCommand = &cobra.Command{ Use: "list-bucket [data dir or db file path]", Short: "bucket lists all buckets.", Run: listBucketCommandFunc, } )

Сравни с этим еще - https://www.npmjs.com/package/yargs

https://kaamos.me/talks/alt16/#/slide-orgheadline1 вот докладец который втаптывает pg :)

А там в статье автор и так и сяк, не нарушая политкорректность, пытается намекнуть что он был еще молод и неопытен, и горел очень идеей, и тогда еще не вышел go, и вот он делал делал. Но потом когда увидел какое говно он сотворил то ему стало стыдно :) А толпы хомячков повалили за модной технологией

Не надо перевирать автора. Он говорит, достословно: "Тогда я был молод и предпочел не самый, как мне кажется сейчас удобный, вариант. В Go концепция "зеленых потоков" гораздо удобнее, чем постоянная асинхронность". По сути, он не говорит, "node.js гавно, подход который я там применил дно придонное". А про хомячков - отмазка не взлетевших, хомячки за собой ничего, кроме хелловорлдов не делают

Поясню мысль. Сейчас есть монолит. В монолите есть схема БД. Схема может немного меняться. К примеру новый столбец может быть добавлен. Есть потребность в микросервисе который бы с этой же БД работал. Проблема в том, что я не могу понять как быть. Толи копировать схему в свой микросервис и непонятно как синхронизировать ее с основной кодовой базой или просто мапить структуру базы данных ничего не описывая. Непонятно к чему последний вариант приведет.

Для меня это темный лес

Не надо перевирать автора. Он говорит, достословно: "Тогда я был молод и предпочел не самый, как мне кажется сейчас удобный, вариант. В Go концепция "зеленых потоков" гораздо удобнее, чем постоянная асинхронность". По сути, он не говорит, "node.js гавно, подход который я там применил дно придонное". А про хомячков - отмазка не взлетевших, хомячки за собой ничего, кроме хелловорлдов не делают

Да он именно ровно это и говорит, просто вежливыми словами ;) И он ведь не против асинхронности, а против того как она сделана в ноде конкретно

А node.js по-прежнему однопоточная поделка?

Сравни с этим еще - https://www.npmjs.com/package/yargs

ИМХО не читабельно.

Да он именно ровно это и говорит, просто вежливыми словами ;) И он ведь не против асинхронности, а против того как она сделана в ноде конкретно

Он не против асинхронности, но считает, что в Go другая концепция, более удачная

А node.js по-прежнему однопоточная поделка?

Файберы есть, вроде, но тут главным образом проблема ЯПа, JS вообще не дружит с многопоточностью пока, увы

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

Вообще JS на сервер-сайде это огромная ошибка. То что он в Вебе закрепился тоже кратковременное завихрение эволюции

ИМХО не читабельно.

Что конкретно нечитабельно? Чейнинги как раз очень читабельная вещь, а объектами выходит почти как на Go

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

А какое отношение к многопоточности имеет модель памяти?

Файберы есть, вроде, но тут главным образом проблема ЯПа, JS вообще не дружит с многопоточностью пока, увы

Ты вчера говорил что d не совсем подходит для написания веб серверов, ну так вот и nodejs не совсем подходит по сравнению с го

Вообще JS на сервер-сайде это огромная ошибка. То что он в Вебе закрепился тоже кратковременное завихрение эволюции

Этому завихрению 20 лет уже, некоторым участникам местных диалогов немногим больше)

Не читабельно из-за обилия скобок.

Вообще JS на сервер-сайде это огромная ошибка. То что он в Вебе закрепился тоже кратковременное завихрение эволюции

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

Не читабельно из-за обилия скобок.

(Впадает в ступор) Т.е. ты: 1. Не посмотрел, что yargs может брать все из одного объекта 2. Считаешь чейнинги нечитабельными?

Ну так а вебсокеты тянут за собой необходимость полноценного сервера с логикой, они же не в вакууме работают. По вебсокетам данные идут и в базу и в кеши и во все остальные системы.

JS чейнинги на мотив кол-беков не читабельны. Не синтаксис, а один сплошной набор скобок

А node.js по-прежнему однопоточная поделка?

Я на нодежс не писал, но вроде есть pm - велосипед который позволяет запустить сразу несколько нодежсов и прибить гвоздями к каждому ядру. А потом еще следит за утекающими процессами, отстреливает их и снова запускает.

Ну так а вебсокеты тянут за собой необходимость полноценного сервера с логикой, они же не в вакууме работают. По вебсокетам данные идут и в базу и в кеши и во все остальные системы.

Не понял, к чему это? Нода не умеет грамотно работать с бд и другими системами?

кстати, по поводу вездесущего js

Не понял, к чему это? Нода не умеет грамотно работать с бд и другими системами?

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

решил я сделать приложение под LG WebOS для телевизора, и оказалось, что помимо очевидного js+html+css, с помощью которого сами приложения делаются, там еще и под капотом nodejs, на котором пишутся системные сервисы)

JS чейнинги на мотив кол-беков не читабельны. Не синтаксис, а один сплошной набор скобок

Колбеки, уважаемый везде есть, не нравится определять на месте - определяйте в другом месте. Это не проблема модуля И да, пункт 1 еще в силе

и всё это на 600 метрах оперативки

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

А я не говорил, что она плоха для остального, я говорил скорее о том, что она выигрывает только на них, в остальном она не выигрывает у других.

@maxfreck щас ноду пихуют вообще черт знает куда и хрен пойми зачем. От Антивирусов до скайпа

а в чем прелесть js для сокетов-то?

решил я сделать приложение под LG WebOS для телевизора, и оказалось, что помимо очевидного js+html+css, с помощью которого сами приложения делаются, там еще и под капотом nodejs, на котором пишутся системные сервисы)

Вспомнил runtime.js

а в чем прелесть js для сокетов-то?

socket.io + отвратная поддержка PHP преусловленых сокетов.

То есть прелесть сокетов в js в том что сокеты в php говно? Вот это логика ?

@maxfreck щас ноду пихуют вообще черт знает куда и хрен пойми зачем. От Антивирусов до скайпа

Как говорил Линус, Just For Fun

То есть прелесть сокетов в js в том что сокеты в php говно? Вот это логика ?

А что такого нелогичного

@maxfreck щас ноду пихуют вообще черт знает куда и хрен пойми зачем. От Антивирусов до скайпа

И вообще, щас пихают не только ноду, а вообще весь веб куда попало

В итоге софт работает хрен пойми как. Я после знакомства с поделиями на базе Электрон вообще от JS шарахаюсь как от огня.

скажем так, чем js лучше того же vibe-core с файберами? (ну если не брать в расчёт, что vibe-core виснет ¯\_(ツ)_/¯)

ну или, для чистоты сравнения, js vs go

В итоге софт работает хрен пойми как. Я после знакомства с поделиями на базе Электрон вообще от JS шарахаюсь как от огня.

Из минусов Electron.js есть только два: отжор памяти и некоторая слоупочность. А так софт как софт, поддерживать и разрабатывать его зачастую проще и нагляднее

Память жрет, тормозит дико, глюков уйму видел много. Нафиг такой софт

А что такого нелогичного

То есть как только в php сделают нормальную асинхронщину и сокеты то использовать nodejs не будет смысла.

скажем так, чем js лучше того же vibe-core с файберами? (ну если не брать в расчёт, что vibe-core виснет ¯\_(ツ)_/¯)

Ты уж извини, я не тыкал пока ни vibe-core, ни Go. Подозреваю, отчасти простота использования, JS to JS так сказать