я про свойства

Как лучше сделать тестирование функций создающих таблицы в БД? Отдельный конфиг с данными для подключения к тестовой базе? В тестах немного опыта, интерсено мнение опытных гоферов.

Немного непонятно просто

пример сложно описать, там много кода на самом деле. просто представь себе три пакета: модели, коллекции, и репозиторий. модели - это структуры, коллекция - интерфейс для работы с множеством моделей, репозиторий - сохраняет/извлекает модели и создает из них множества(коллекции).

Как лучше сделать тестирование функций создающих таблицы в БД? Отдельный конфиг с данными для подключения к тестовой базе? В тестах немного опыта, интерсено мнение опытных гоферов.

зачем там вообще тесты?

репозиторий (допустим метод Query который выбирает откуда-то данные) делает так: c := NewProductCollection() // например, делаю выборку из базы for rows.Next() { c.Push(model.Product) } c.Lock() // блокирую коллекцию от изменений return c // возвращаю коллекцию, и её могут только читать в другом месте c.Unlock() сделать не получится, т.к. заблокирована она была на этапе создания, тоже самое, когда мы хотим сохранить коллекцию в базу, мы допустим вычитали тело запроса из JSON, создали коллекцию и запушили туда наши модели, и сразу заблокировали, и передали это все в репозиторий, который может только прочитать из этой коллекции.

зачем там вообще тесты?

Разве это не нужно протестить? Может SQL коряво написан или еще что?

Как лучше сделать тестирование функций создающих таблицы в БД? Отдельный конфиг с данными для подключения к тестовой базе? В тестах немного опыта, интерсено мнение опытных гоферов.

думаю тут только функциональные с базой поднятой на докере

репозиторий (допустим метод Query который выбирает откуда-то данные) делает так: c := NewProductCollection() // например, делаю выборку из базы for rows.Next() { c.Push(model.Product) } c.Lock() // блокирую коллекцию от изменений return c // возвращаю коллекцию, и её могут только читать в другом месте c.Unlock() сделать не получится, т.к. заблокирована она была на этапе создания, тоже самое, когда мы хотим сохранить коллекцию в базу, мы допустим вычитали тело запроса из JSON, создали коллекцию и запушили туда наши модели, и сразу заблокировали, и передали это все в репозиторий, который может только прочитать из этой коллекции.

Если у тебя всё и так через интерфейс, почему нельзя просто использовать какой-нибуль флаг в структуре?

Потом реализовать сами функции с проверкой флага и с возвращением ошибок

Моя не понимать

Моя пас

Как лучше сделать тестирование функций создающих таблицы в БД? Отдельный конфиг с данными для подключения к тестовой базе? В тестах немного опыта, интерсено мнение опытных гоферов.

операции с бд (репозиторий) отдельным тест степом с отдельной базой

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

Как лучше сделать тестирование функций создающих таблицы в БД? Отдельный конфиг с данными для подключения к тестовой базе? В тестах немного опыта, интерсено мнение опытных гоферов.

делаешь подключение к fake базе в TestMain, базу поднимаешь в докере/локально, в TestMain делаешь создание/снос БД

Потом реализовать сами функции с проверкой флага и с возвращением ошибок

да, это через флаг и работает, в целом. проблема в том, что если методы публичный, то Lock()/Unlock() может делать кто угодно, а не только создатель коллекции.

репозиторий (допустим метод Query который выбирает откуда-то данные) делает так: c := NewProductCollection() // например, делаю выборку из базы for rows.Next() { c.Push(model.Product) } c.Lock() // блокирую коллекцию от изменений return c // возвращаю коллекцию, и её могут только читать в другом месте c.Unlock() сделать не получится, т.к. заблокирована она была на этапе создания, тоже самое, когда мы хотим сохранить коллекцию в базу, мы допустим вычитали тело запроса из JSON, создали коллекцию и запушили туда наши модели, и сразу заблокировали, и передали это все в репозиторий, который может только прочитать из этой коллекции.

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

и тогда получится то, что вы хотите

но все это пахнет джавой и плохим дизайном, на мой вкус

да, это через флаг и работает, в целом. проблема в том, что если методы публичный, то Lock()/Unlock() может делать кто угодно, а не только создатель коллекции.

Так не создавайте функцию unlock ?

Изи

да, действительно изи) ладно, может и без иммутабельности запилю, спасибо

ok ) отличный результат, очень наглядно

надо ещё алгоритмы других решетов будет потестить )

Или sync.Map

Он блокирует всю мапу? Т.е. у меня горутина пишет в одну ячейку. Мне не надо блокировать всю мапу целиком а только эту ячейку...

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

Он блокирует всю мапу? Т.е. у меня горутина пишет в одну ячейку. Мне не надо блокировать всю мапу целиком а только эту ячейку...

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

Он блокирует всю мапу? Т.е. у меня горутина пишет в одну ячейку. Мне не надо блокировать всю мапу целиком а только эту ячейку...

она умная.

она умная.

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

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

Ну у меня и так несколько поменьше. Просто они лежат в мапе общей. И время доступа к ним О(1). В чем хранить маленькие мапы если ее в другой мапе?

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

sync.Map это НЕ sync.Mutex + map.

sync.Map это НЕ sync.Mutex + map.

а что? https://golang.org/src/sync/map.go

Ну у меня и так несколько поменьше. Просто они лежат в мапе общей. И время доступа к ним О(1). В чем хранить маленькие мапы если ее в другой мапе?

для чтения можно использовать RWMutex

Да меня больше наверно интересует 2 вопроса: 1. Почему происходит блокировка? Ведь это тот же массив, я могу читать и писить в ячейку одним потоком без блокировки если другие пишут в другой

В другие ячейки

для чтения можно использовать RWMutex

Писать*

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

а что? https://golang.org/src/sync/map.go

Чуток более сложная штука

Сам же ссылку дал

Чуток более сложная штука

сложнее, согласен, но просто более оптимизированная

для некоторых случаев

сложнее, согласен, но просто более оптимизированная

Ну поэтому все же оно не мапа с мьютексом, ведёт себя иначе

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

Ну у меня и так несколько поменьше. Просто они лежат в мапе общей. И время доступа к ним О(1). В чем хранить маленькие мапы если ее в другой мапе?

так из общей мапы вы же только читаете?

Да меня больше наверно интересует 2 вопроса: 1. Почему происходит блокировка? Ведь это тот же массив, я могу читать и писить в ячейку одним потоком без блокировки если другие пишут в другой

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

#работа #remote Всем привет! Ищу экспертов с большим практическим опытом в GO, готовых передавать свои знания другим! Занятость преподавателя складывается из проведения вебинаров и проверки домашних заданий студентов. И то, и другое оплачивается. Продолжительность одного курса -около 5 месяцев. Преподавать можно в любой точке мира, без отрыва от основной работы. Есть вариант записи видеокурса. От вас не требуется опыт преподавания, мы с удовольствием и бесплатно научим вас учить! С радостью отвечу на все вопросы. Лучше в личку

#работа #remote Всем привет! Ищу экспертов с большим практическим опытом в GO, готовых передавать свои знания другим! Занятость преподавателя складывается из проведения вебинаров и проверки домашних заданий студентов. И то, и другое оплачивается. Продолжительность одного курса -около 5 месяцев. Преподавать можно в любой точке мира, без отрыва от основной работы. Есть вариант записи видеокурса. От вас не требуется опыт преподавания, мы с удовольствием и бесплатно научим вас учить! С радостью отвечу на все вопросы. Лучше в личку

@gogetajob

Ребят, хочу написать свою небольшую KV БД, что от нее требуется 1) возможность insert/delete, update не нужен 2) очень быстрая запись 3) индекс по ключу 4) возможность "постраничной" подгрузки в память, чтобы не держать все в RAM

существующие решения какой-то оверхед

что можно почитать? с чего начать?

Ребят, хочу написать свою небольшую KV БД, что от нее требуется 1) возможность insert/delete, update не нужен 2) очень быстрая запись 3) индекс по ключу 4) возможность "постраничной" подгрузки в память, чтобы не держать все в RAM

какой порядок количества ключей?

что можно почитать? с чего начать?

https://github.com/Netflix/rend реализиция протокола, метрики, общий дизайн

Ребят, хочу написать свою небольшую KV БД, что от нее требуется 1) возможность insert/delete, update не нужен 2) очень быстрая запись 3) индекс по ключу 4) возможность "постраничной" подгрузки в память, чтобы не держать все в RAM

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

ошизенный ответ %))

на ноду сколько? лям? 10? 100? 10 тысяч? 100 тысяч?

соре

какой порядок количества ключей?

может быть 1млн, а может быть и все 100млн

может быть 1млн, а может быть и все 100млн

на один сервер или на несколько?

на ноду сколько? лям? 10? 100? 10 тысяч? 100 тысяч?

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

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

какой тип базы в рамках CAP теоремы?

Мне конечно очень стыдно, но я не могу ответить на этот вопрос

да забей на "стыдно", пойди погугли и выбери

существующие решения какой-то оверхед

Чисто из интереса, какие решения вы смотрели?

ERROR: S client not available

Чисто из интереса, какие решения вы смотрели?

badger, buntdb badger - не нужные мне MVCC, + кажется очень громоздким и тяжелым, быстро работает на многопоточности buntdb - тоже отличная база, очень быстрая на запись, не нравится что ключ-значение только строки, и надо конвертить в строка-слайс-байт и обратно при хранении, + медленно работает на многопоточности. На одном потоке работает сильно быстрее чем badger по моим тестам. Куча индексов, которые мне не нужны

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

спасибо, напишу заранее перед этим тогда

Ребят, хочу написать свою небольшую KV БД, что от нее требуется 1) возможность insert/delete, update не нужен 2) очень быстрая запись 3) индекс по ключу 4) возможность "постраничной" подгрузки в память, чтобы не держать все в RAM

да, думаю много нюансов, которые я совсем не учел

badger, buntdb badger - не нужные мне MVCC, + кажется очень громоздким и тяжелым, быстро работает на многопоточности buntdb - тоже отличная база, очень быстрая на запись, не нравится что ключ-значение только строки, и надо конвертить в строка-слайс-байт и обратно при хранении, + медленно работает на многопоточности. На одном потоке работает сильно быстрее чем badger по моим тестам. Куча индексов, которые мне не нужны

Не знаю, может вам что то приглянется из готового https://www.g2crowd.com/categories/key-value-stores

https://github.com/Netflix/rend реализиция протокола, метрики, общий дизайн

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

Не знаю, может вам что то приглянется из готового https://www.g2crowd.com/categories/key-value-stores

хотелось бы именно embedded решение, boltdb не пробовал, но по отзывам может запросто покалечить данные и вроде как исправлять не собираются

А как на счёт leveldb?

хотелось бы именно embedded решение, boltdb не пробовал, но по отзывам может запросто покалечить данные и вроде как исправлять не собираются

.

А как на счёт leveldb?

посмотрю, спасибо

Здравствуйте, как можно выделить память через kernel32.NewProc("VirtualAlloc"), я просто в сисколах не разбераюсь и не знаю какие нужны аргументы для сискола

Здравствуйте, как можно выделить память через kernel32.NewProc("VirtualAlloc"), я просто в сисколах не разбераюсь и не знаю какие нужны аргументы для сискола

если ты не разбираешься в сисколлах, зачем тебе такая аллокация?

если ты не разбираешься в сисколлах, зачем тебе такая аллокация?

Не важно зачем, я просто хочу узнать как это можно сделать

Это запрещено делать на вин10 uwp

все можно сделать

можно, но на uwp нет virtualalloc

вопрос - -н-а-х- зачем?

вопрос - -н-а-х- зачем?

не знаю, сначала думал быстро увеличить allocation для повышения производительности хоть в golang стоит garbage collector

если я буду из нескольких горутин работать с мапой без мьютекса - будет плохо?

если я буду из нескольких горутин работать с мапой без мьютекса - будет плохо?

Да, может быть плохо

А как на счёт leveldb?

Это не база, а движок хранилища, и его, вроде, нет на go нативного

Посоветуйте материал для обучения

Да, может быть плохо

Эх, если бы только был язык, который предотвращал подобные ошибки на этапе компиляции. Но это только мечты...

если я буду из нескольких горутин работать с мапой без мьютекса - будет плохо?

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

если я буду из нескольких горутин работать с мапой без мьютекса - будет плохо?

Если модифицировать — то да. Если все только читают — то норм

Эх, если бы только был язык, который предотвращал подобные ошибки на этапе компиляции. Но это только мечты...

Первая ява.

Первая ява.

То есть?

Кстати насчет ошибок чтоб 100500 раз не компилировать вроде бы в Visual Studio есть плагин который отслеживет ошибки, как только ты сохраняешь файл ctrl+s у тебя подствечиваетася зеленым или красным (красным там где ошибка) оооочень полезный плагин

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

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

А. Ну, такое

если я буду из нескольких горутин работать с мапой без мьютекса - будет плохо?

Есть sync map вроде