Да, но в создании нет primary key

INSERT INTO "users" ("created_at","updated_at","deleted_at","first_name","last_name","user_name") VALUES ('2017-09-06 21:15:53','2017-09-06 21:15:53',NULL,'dima','','') [1 rows affected or returned ]

Следовательно и в добавлении записи

в другой таблице CREATE TABLE "notifications" ("id" integer primary key autoincrement,"created_at" datetime,"updated_at" datetime,"deleted_at" datetime,"coin" varchar(255),"greater" bool,"value" real )

стандартный айдишник норм работает, но мне нужен мой

че блин делать тут

INSERT INTO "users" ("created_at","updated_at","deleted_at","first_name","last_name","user_name") VALUES ('2017-09-06 21:15:53','2017-09-06 21:15:53',NULL,'dima','','') [1 rows affected or returned ]

Зачем те created at updated at...?

Зачем те created at updated at...?

Да то стандратные, снесу их наверно

UserId

Чо с маленькой

Приватные не пишутся в бд

Приватные не пишутся в бд

моё увожение.

просто брать таблицу и редачить column?

будет ли тогда корректно вносить новые объекты?

будет ли тогда корректно вносить новые объекты?

Да

Да

переименовать column ,я так понял, будет непросто

всем привет, новичок в go. подскажите пожалуйста, какая должна быть структура у rest api приложения на go? может репозиторий какой скинете в качестве примера? всем откликнувшимся спасибо

всем привет, новичок в go. подскажите пожалуйста, какая должна быть структура у rest api приложения на go? может репозиторий какой скинете в качестве примера? всем откликнувшимся спасибо

https://github.com/go-chi/chi/tree/master/_examples/rest

https://github.com/go-chi/chi/tree/master/_examples/rest

спасибо, но я так и не понял, это нормально, что все файлы лежат в одной папке?

всем привет, новичок в go. подскажите пожалуйста, какая должна быть структура у rest api приложения на go? может репозиторий какой скинете в качестве примера? всем откликнувшимся спасибо

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

Это называется пакет

спасибо, но я так и не понял, это нормально, что все файлы лежат в одной папке?

Нормально, если свободные имена не кончаются:)

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

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

на js ты пишешь

все аналогично

кроме работы пакетов

разбивал по юнитам разбивай и дальше так

спасибо, но я так и не понял, это нормально, что все файлы лежат в одной папке?

мне показалась удобной структура как тут - https://github.com/labstack/echox/tree/master/cookbook/twitter

можно еще разбивать по функциональностям

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

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

это скорее во фреймворках :) , называется Convention over configuration

я обычно бью на domain infrastructure interfaces и тп

это скорее во фреймворках :) , называется Convention over configuration

ну значит наверное надо мне найти что-то стоящее для gin )

посмотри buffalo

а то все что видел какое-то фу по огранизации кода, файлы по 300-500 строк, все в одной папке

и еще что-то было

start small grow big

buffalo больше для web страничек

откинь view слой

делов

ладно, еще раз по частям вопросы) 1. модели описываются в одном файле или дробятся на отдельные сущности? 2. роуты в одном файле или делятся на отдельные файлы? 3. как в го с вложенностями папок (еще не увидел проектов с большой вложенностью) 4. есть ли какие-то каноны именования папок/файлов? 5. почему на гитхабе много проектов со всеми исходниками в корне? Хочу для себя переписать проект с ноды на го (за основу решено взять фреймворк gin), чтобы попрактиковаться, бенчмарки сделать и др

@konyaev https://github.com/kubernetes/kubernetes/tree/master/federation/pkg/federation-controller/service/ingress большая вложенность?

достаточная )

Очевидно, что можно делать как угодно и это ни на что не влияет

)

Очевидно, что можно делать как угодно и это ни на что не влияет

есть все равно что-то, чего все придерживаются

Почему ты так думаешь?

так учили в школе

и в универе

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

что есть что-то куда нужно смотреть и правильно отвечать

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

Тогда зачем вопрос? Посмотри на проекты и увидишь одинаковую структуру

Тогда зачем вопрос? Посмотри на проекты и увидишь одинаковую структуру

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

почему на гитхабе много проектов со всеми исходниками в корне? из-за специфики вендоринга, а именно отсутсвие единого реестра пакетов

go get -u github.com/etc/etc

и потом import github.com/etc/etc

решил спросить в специализиованной группе, а свелось к тому, как учили меня в школе или универе

вот посмотри как работает https://github.com/golang/dep

Очевидно, что можно делать как угодно и это ни на что не влияет

как тебя занесло в го?

Ну тебя просто ответ: нет стандартов, делай как удобно, не устраивает

как тебя занесло в го?

Все там будем

вот посмотри как работает https://github.com/golang/dep

спасибо, много в закладки уже чего положил.

Ну тебя просто ответ: нет стандартов, делай как удобно, не устраивает

извиняюсь за грубость, но вы что-нибудь делали серьезнее hello world в команде?

Да

Все там будем

стандартизация и макаки over выразительность и специалисты?)

Да

значит кто-то работая с вами страдал

это не точно

стандартизация и макаки over выразительность и специалисты?)

Не, я за выразительность с блэкджэком и дженериками

стандартизация и макаки over выразительность и специалисты?)

Стандартизация и специалисты. Выразительность не работает

Стандартизация и специалисты. Выразительность не работает

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

я вот нод разраб в прошлом да блядь и в будущем

нет никакой разницы

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

есть все равно что-то, чего все придерживаются

Почему ты так думаешь?

так учили в школе

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

очень приятно)

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

Я кладу апишку в одну папочку во много файликов, бизнес-логику в другую, repo (базу) - в третью. И в корне один единственный main.go, который всё связывает.

Пока проект небольшой, всё хорошо, а дальше уже думать)

index js разительно отличается от main go

Я кладу апишку в одну папочку во много файликов, бизнес-логику в другую, repo (базу) - в третью. И в корне один единственный main.go, который всё связывает.

это то, что я хотел услышать ? спасибо

значит кто-то работая с вами страдал

у GO один способ сделать что-то, например есть оператор for для обхода коллекций и все :) А в Ruby, например - each, map, inject, each_with_index и each_with_object . Придумывать каки-то еще договоренности помимо имеющихся в языке отпадает необходимость, на мой взгляд.

Я кладу апишку в одну папочку во много файликов, бизнес-логику в другую, repo (базу) - в третью. И в корне один единственный main.go, который всё связывает.

тут какой-то подвох!

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

Подколол. Ха.

Подколол. Ха.

никаких подколов, правда

Мне пакаджинг по версиям в го не нра. Как впрочем и везде

у GO один способ сделать что-то, например есть оператор for для обхода коллекций и все :) А в Ruby, например - each, map, inject, each_with_index и each_with_object . Придумывать каки-то еще договоренности помимо имеющихся в языке отпадает необходимость, на мой взгляд.

Для некоторых вещей даже 0 способов

@RShishkin хорошо бы это все разрулил

А так за шаг влево вправо расстрел язык нравится

Напоминает то чем в своё время была жава 1.1 )

а по структуре проектов в сравнении с нодой как вы организовываете все в го?

Главное чтобы не началась игра в "хочу быть жавой"

а по структуре проектов в сравнении с нодой как вы организовываете все в го?

Пока никак. Я играюсь с инструментом пока

index js разительно отличается от main go

вообще не имеет отношения к упаковке. имеет отношение, что у ноды есть package.json, а в го пока все экспериментальное