Golang: Пакет для мульти-логирования на основе log/Slog

А ещё для slog fanout реализует вот такая библиотека

https://github.com/samber/slog-multi

Автоматическое обновление заметок в Joplin

Пробовал Obsidian, но уже не помню почему отказался в пользу Joplin. А чем синхронизация проще? Если верно понял, для Obsidian можно просто синхронизировать каталог с данными сторонним софтом?

Синхронизация Joplin плохо работала для WebDAV с яндекс.диском, для больших файлов. Для S3 полет нормальный

Автоматическое обновление заметок в Joplin

Да, логика не очень, но что имеем

Пожалуйста, рад что ресерч оказался полезен:)

Автоматическое обновление заметок в Joplin

Нет, такую информацию можно получить только выгрузив контент файлов. В названии в S3 используется формат <id>.md. Все, что касается типа файла, родительского элемента итп лежит в метаданных в самом файле. Например, параметр type_будет определять тип.
То есть, в любом случае для S3 изначально придется получить все файлы, чтобы по ним построить зависимости. Далее можно при повторной синхронизации подтягивать изменения и применять их к локальным данным. Так делают сейчас клиенты, судя по их логам при синхронизации

Автоматическое обновление заметок в Joplin

Спасибо

1. Я упомянул про инсталляцию joplin server как цели синхронизации, в self-hosted варианте. Это тот случай, который я не стал реализовывать: не захотелось лезть в закрытый API. Технически это даже проще, чем поднять API от CLI, надо только поизучать запросы. И все клиенты переключить на self-hosted сервер как цель синхронизации
   В моем случае цель синхронизации это бакет в S3, и клиент синхронизируется с ней

2. Смотрел логи S3 по времени обновления. В моем случае, для обновления заметки, не понадобилось трогать diff файлы: обновления контента и даты оказалось достаточно

3. Да, UX такой себе. Joplin offline-first софтина с возможностью синхронизации. Написание альтернативного клиента сведется к написанию своего софта для заметок, который будет совместим с форматом хранилищ. Ограничений нет, просто в реальном клиенте куча деталей вроде упомянутых diff файлов
   Для клиента я бы начал с поддержки API сервера как раз, хоть он и не публичный.

Чистые транзакции в гексагональном Go

Спасибо за подробный ответ. А для исходящих портов применяете интеграционные тесты?

Чистые транзакции в гексагональном Go

Отвечу за автора. Замыкание вызывается для зависимости. Если тест unit, то зависимости будут замоканы. Инструменты вроде gomock позволяют мокать замыкания

Чистые транзакции в гексагональном Go

Согласен, напрямую использовать не будет удобно. Для того хелпер: объект бд/транзакции скрыт за TX(), аналогично WithinTransaction(). Иницилизировать репозиторий придется только в случае, когда метод нужен внутри транзакции. В этом смысле реализация с контекстом возможно удобнее

carRepo.Tx(func(txRepo CarRepository)error{
  err = txRepo.Method1()
  if err != nil {
    return err
  }
  
  customerTxRepo = NewCustomer(txRepo.DB())
  return customerTxRepo.Method2()
})

Чистые транзакции в гексагональном Go

Я выделил интерфейс

QueryExecutor interface {
		ExecContext(ctx context.Context, query string, args ...interface{}) (sql.Result, error)
		QueryRowContext(ctx context.Context, query string, args ...interface{}) *sql.Row
		QueryContext(ctx context.Context, query string, args ...interface{}) (*sql.Rows, error)
	}

Его имплементят sql.Tx и sql.DB, от него зависят репозитории, передается в конструктор

type CarRepository interface{
  DB() QueryExecutor
}

type repo struct{
  db QueryExecutor
}

func NewRepo(db QueryExecutor) CarRepository {
  return &repo{db: db}
}

Так в транзакции можно вызывать NewRepo(tx) где tx типа sql.Tx

Сделал вот такой хелпер https://github.com/andrdru/sqltx
Также использовал замыкание. В интерфейс репозитория добавляю метод

TX(action func(txRepo CarRepository) error) error

который уже будет вызван в логике

Из недостатков - из репозитория торчит метод DB() QueryExecutor, который позволяет получить в замыкании sql.Tx.