Нууу смотри. Я бы в этом случае плясал от ORM-а или того, как ты собираешься с базой вообще работать

Потому что их нет в ноде вообще

Ладно, вообще есть конечно. Но чего-то уровня Hibernate или SQLAlchemy нету

Потому что их нет в ноде вообще

Бомбит от этого нереально

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

Ну... сформулирую тогда проще. Мне вот хочется запилить POJO, развесить аннотации, и чтобы весь этот lazy fetch и заодно проблему N+1 из коробки решало. Ну и ясно, что как самый яркий самородок из Сибири, базу я в конце обязательно поменяю с бесплатного оракла на древний ms sql )

Но если есть ссылки - я с радостью гляну

Не, я ж не спорю, что написать можно. Я про готовое спрашиваю)

Бомбит от этого нереально

ну скажем так, на ноде, имхо, конечно, значительно реже и потребность такая возникает. Хотя, конечно, возникает эпизодически. Если хочется прям хороший конструктор, то не смотря на все эти ноды и прочее популярное.. ну слушай, Java - твой выбор. Вот та самая со спрингом и гибернейтом. Как бы не хотелось, чтобы было наоборот, пока это самый прямой и фиче-рич выбор

Туповато, да. Но хм.. Netty сейчас если не рвёт вообще всех, то стабильно в топе. Кодится оно просто, прямо и тупо.

Меня ведь не выпилят за это из чатика??))

Не, норм

Там еще про neo4j говорили)))

Если никто не пишет, то возникает резонный вопрос - а почему?) Наверняка есть некая причина..

Вполне возможно просто потому, что в мире нужен ровно один Hibernate)

Ну вот смотри, odbc - не самая популярная штука

https://www.npmjs.com/package/odbc

А как без odbc/jdbc/чего-то такого жить вообще ?

Плюс очень хитрый вопрос с асинхронностью. Если я ничего не путаю (а я могу), то большинство баз очень плохо любят асинхронную работу. А без connection pool-а никак. А потоков-то в JS нет. И вот мы уже пишем native library для ноды)

Соглашусь с предыдущим оратором, базе собственно всё равно 10 запросов выполнять или 500, на серваке просто лягут диски, все упрется в io

Никто в протоколе монги не разибрается?

А то документация какая-то вялая

А при том, что connection pool нужен не для pg, а вообще для всех типов БД. И если, условно, в Java это все есть в рамках JDBC со товарищи, то в ноде еще это все предстоит реализовать руками. И тогда, когда последний раз (правда это было давно) я работал с базой напрямую руками - с асинхронным io всё было очень не сладко. Примерно вот так: http://stackoverflow.com/a/7616094/1040070 Насколько знаю, сейчас это куда-то подвинулось, но вообще говоря суть не в этом. Суть в том, что перед тем как строить абстрактный ORM - под него надо еще и фундамент построить. Поправьте, если ошибаюсь, но в ноде, кажется ничего такого нет ни стандартного, ни стандарта де-факто.

Никто в протоколе монги не разибрается?

Могу посоветовать только поковырять драйвер

Ну это очевидно

Но это не дает прямых ответов

Приходиться ковырять вообще все драйвера на всех языках, чтобы сделать выводы

В ноде очень очевидный драйвер, btw

Да не очень

Там за слоем сахара и проверки типов плохо читается суть

Я в 2.1 ковырялся - все было просто и понятно, афаик

Плюс разбито на два пакета

С дублированием сущностей

Я, правда, не пытался его понять в целом, просто дебажил конкретную проблему

Я решил свой драйвер замутить

Не уверен, но может вот это поможет: https://github.com/ReactiveMongo/ReactiveMongo/tree/master/driver/src/main/scala/api/commands

Я решил свой драйвер замутить

👍

Да явно придется все драйвера посмотреть

Но мне нужен минимум функционала

Йоу, никто не работал с пушами от ЯД? Суть в том, что сервер пушит ид операции таким 1080960751286090000 Нормальное число должно быть 1080960751286090017 Это связано с ограничениями ЖСа, как побороть, не знаете?

Яд отдает числом, а не строкой 😒

В чем отдает? Json?

Ага

Тогда увы

Придется брать парсер на js и его модифицировать

reviver свой ставить пробовал?

Там уже поздно

В принципе можно поробовать регэкспом накрыть

А, оно туда не сырые данные пихает?

Но это не особо надежно

Реэкспом найти "my_field": \d+

Или как вариант - регулярочкой заменить все 123456 на "123456" и парсить как обычный JSON, но уже со строками вместо чисел.

Народ - нужна помощь - возможно нубский вопрос

Перелопачивал легаси es5 на es6 - столкнулся с проблемой что перемнные объявленные до условий в них не видны - кроме возврата к var не вижу выхода. Было так: var variable; if (cond) { variable = new_value; } Сделал let variable; if (cond) { variable = new_value; }

Плохо ли вернуться к var?

Для таких случаев?

const - если хочешь пометить переменную как константа let - если хочешь ограничить область видимости переменной блоком var - если хочешь просто объявить переменную

С чего все вдруг взяли что var - это зло?

es6 же вроде

и чо?

аргументация нормальная есть, кроме того что es6?

Все, сорян - понял где протупил

Не в том блоке была

Спасибо

Перелопачивал легаси es5 на es6 - столкнулся с проблемой что перемнные объявленные до условий в них не видны - кроме возврата к var не вижу выхода. Было так: var variable; if (cond) { variable = new_value; } Сделал let variable; if (cond) { variable = new_value; }

Вы уверены что variable не доступна в блоке? Как мне кажется let не доступен из вне, но доступен внутри своих блоках

и чо?

К примеру - https://github.com/airbnb/javascript#references

Вы уверены что variable не доступна в блоке? Как мне кажется let не доступен из вне, но доступен внутри своих блоках

Да, вы правы - просто в старом коде она была объявлена не в том блоке - а т.к. он пеленой шел - я не заметил

Да, вы правы - просто в старом коде она была объявлена не в том блоке - а т.к. он пеленой шел - я не заметил

И только спустя 5 минут выяснил это)

Да, вы правы - просто в старом коде она была объявлена не в том блоке - а т.к. он пеленой шел - я не заметил

Да, такое бывает :)

К примеру - https://github.com/airbnb/javascript#references

Это стайлгайд который выбрала себе airbnb, аргументации кроме того что они блочные нет.

Ну линтер в вебшторм встроенный ругается на var если выбран es6

Ну линтер в вебшторм встроенный ругается на var если выбран es6

На самом деле Andrew прав, var и правда можно юзать в es6, просто ваш вопрос касался больше как раз стайлинга.

Ну линтер в вебшторм встроенный ругается на var если выбран es6

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

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

Спасибо

rc1

я имею ввиду, что не вышел

С чего все вдруг взяли что var - это зло?

А какие плюсы у var перед let ? Ну кроме hoisting, которые едва ли достоинство?

а в том то и соль что по большому счету похер что ты используешь, если понимаешь как это работает. Если ты понимаешь как работает var, пользуйся им, если знаешь как работает let - юзай его, но он тебе не всегда подойдет. Так что ты можешь использовать в коде 3 типа объявлений и они не будут пересекаться по назначениею.

а в том то и соль что по большому счету похер что ты используешь, если понимаешь как это работает. Если ты понимаешь как работает var, пользуйся им, если знаешь как работает let - юзай его, но он тебе не всегда подойдет. Так что ты можешь использовать в коде 3 типа объявлений и они не будут пересекаться по назначениею.

ты предпочитаешь var использовать?

мне eslint запрещает использовать var, потому что используем конфиг airbnb. Но я не вижу ни одного минуса в использовании var.