Не обвинение, а предположение. Сообщение выше про базу выставленную наружу

и чего неверного в том, что бд нельзя шарить в публичную сетку?

То что sql это не база

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

Ну вот либо ты не понял человека, либо не знаешь что такое sql.

о боже, давайте завершать этот нонсенс

я лишь оспариваю твоё утверждение о том что асимметричное шифрование это якобы "проще, быстрее и надёжнее"

Боже тут ни причём) нонсенса тоже нет, просто ты при недостаточной компетенции весьма вольно трактуешь чужие слова не до конца понимая их) Но да, завершим это.

я попрошу оставаться на уровне темы, а не спускаться на уровень личностей. я человека понял, но он не понял GQL. ещё раз повторюсь, что 2 возможных варианта использования SQL в сервер-клиент коммуникации: 1. SQL как язык API 2. SQL как язык прямого обращения к публичной БД очень плохие варианты. очень. во втором варианте большие проблемы безопасности. а в первом варианте просто нет смысла. query { customer(id: "xyz") { friends(ageRange: 18_to_25) { name employer { name } } } } напишите подобный запрос в SQL... а потом напишите движок, который способен будет этот SQL пропарсить, проверить, валидировать и... разница GQL и SQL станут очевидны

Причём тут разница gql vs sql? Ты вот говоришь, но сам не слышишь)

и что я не слышу?

Зачем какой-то новый язык запрос изобретать.

@snipnick это относилось к GQL

Ну так ты мне приводит доводы gql vs sql, а я их не сравнивал, я сделал предположение о твоём понимании что такое sql

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

Коллеги, хватит

ну нельзя ставить под вопрос компетентность человека без обоснований, это равносильно унижению, некрасиво и неправильно

Помогите. Использовал Sublime, стоял GoSublime, Потом перестал работать автокомплит. GOPATH по советам в интернете вроде поставил, но ничего не поменялось.

В общем, переход Go на другую модель пакетов поломал gocode и пока какие-то странные решения.

Vscode

Помогите. Использовал Sublime, стоял GoSublime, Потом перестал работать автокомплит. GOPATH по советам в интернете вроде поставил, но ничего не поменялось.

linux?

Если тема пройдет в массы, этим и должно будет все закончится. Как по мне, это самый логичный способ. Ну может не табличку отдавать, а может и табличку, но не одну... Но sql отличный язык для этого.

коллега, вы спятили? извиняюсь за дурной тон, но отдавать базу в сеть это неимоверный нонсенс, это просто верх маразма, мне даже лень вам объянять это потому-что это должно быть очевидным. API уровень существует не ради того чтобы потратить лишнее время программиста, а ради того чтоб защитить бд от возможных опасностей и сделать её более доступной для приложения

Вы зря так кипятитесь. См. postgrest. backendless решения доказали право своё на жизнь. Люди прекрасно себя чувствуют без всяких апи и костылей в виде этих ваших графкуэлей и свагеров

Есть конечно, там же написано на оф сайте. Есть ещё nosql фреймворки, которые прям из фронта лупят в монгу. Что как бы намекает

Я когда говорю про SQL, я не говорю про БД, а про интрерфейс. Можно например запрашивать данные из фейсбука посредством SQL запросов, или любые другие, только драйвер нужен, который обработает этот запрос. Любой GQL запрос, при условии что на бэке стоит реляционная БД, будет преобразован к SQL запросу, так что любой возможный запрос GQL будет мапиться в SQL, иначе это не имеет смысла. Я там выше писал, что возможно в "таблица" как ответ будет не самым лучшим вариантом, но никто и не говорил, что SQL должен описывать как именно должны быть представленны данные, а только их набор. Так вот если маппинг в итоге есть GQL -> SQL, логично ожидать, что кто-то не будет заморачиваться с еще одним языком, а прикрутит подмножество SQL. Лично я в этом случае более охотно его использую.

Вы зря так кипятитесь. См. postgrest. backendless решения доказали право своё на жизнь. Люди прекрасно себя чувствуют без всяких апи и костылей в виде этих ваших графкуэлей и свагеров

Да, так надо делать. Прям с фронта - и в общую базу. Make SQL injection great again

предлагаю эксперимент query { customer(id: "xyz") { friends(ageRange: 18_to_25) { name employer { name } } } } в SQL и с соответствующим парсером.

Коллега, вы отстали от жизни. В постгресте это всё более или менее решено

Коллега, вы отстали от жизни. В постгресте это всё более или менее решено

Так в этом нет никакой магии, вот эти движки, которые вы обсуждаете и занимаются тем, что парсят этот запрос и преобразуют его к виду SQL

Я когда говорю про SQL, я не говорю про БД, а про интрерфейс. Можно например запрашивать данные из фейсбука посредством SQL запросов, или любые другие, только драйвер нужен, который обработает этот запрос. Любой GQL запрос, при условии что на бэке стоит реляционная БД, будет преобразован к SQL запросу, так что любой возможный запрос GQL будет мапиться в SQL, иначе это не имеет смысла. Я там выше писал, что возможно в "таблица" как ответ будет не самым лучшим вариантом, но никто и не говорил, что SQL должен описывать как именно должны быть представленны данные, а только их набор. Так вот если маппинг в итоге есть GQL -> SQL, логично ожидать, что кто-то не будет заморачиваться с еще одним языком, а прикрутит подмножество SQL. Лично я в этом случае более охотно его использую.

А как он проверяет что у пользователя есть права?

кто пробовал запускать go-tdlib ? [ 1][t 1][1537212656.747661829][TdDb.cpp:381][!Td] Destroy bad sqlite db because of: [Error : 0 : Wrong key or database is corrupted] 2018/09/17 19:30:56 NewClient error: 0 disk I/O error

да я пример main.go запускаю

Решено это в couchdb. Но чет мало кто готов на ней делат проекты

./.tdlib/... и тд создаються запускаю в вагранте

они туда и GQL уже завезли?

UseFileDatabase: true, // тут ставим false будет работать

:) первым делом попробовал, не понятно зачем там sqlite если и так вроде состояние сохраняет

Вы зря так кипятитесь. См. postgrest. backendless решения доказали право своё на жизнь. Люди прекрасно себя чувствуют без всяких апи и костылей в виде этих ваших графкуэлей и свагеров

а как он борется с underfetching'ом?

Есть конечно, там же написано на оф сайте. Есть ещё nosql фреймворки, которые прям из фронта лупят в монгу. Что как бы намекает

Не готов ответить, я в данном случае не настоящий сварщик. Знаю лишь что меры принимаются

учитывая что REST это RPC а RPC решает underfetching только способом добавления специализированных endpoint'ов - звучит не очень.

после перезагрузки не сохранится состояние

Как я понял там на каждую вьюху генерятся автоматически ендпойнты соответствующие. Вьюхи докинуть до кучи не проблема. По этому скорее всего решение накидать вьюху на все случаи жизни. Я так думаю

честно говоря я очень скептически отношусь к слиянию API и DB если endpoint только читает/записывает в бд то на первый взгляд кажется что зачем нужен API?! но потом если нужно реализовать... какие-то особенности в системе прав, посылку мыла вычисления обратную связь (server-side events) и т.д. и т.п. и всё это в бд? звучит слишком хаотично.

Pl sql +расширения решают

PI sql?

а на новые сообщения есть возможность подписаться?