Как я уведомляю процесс изменения базы данных SQLite, сделанного в другом процессе?
Это связано со структурой виджета Image и его конструктором Image.network, который кэширует все загруженные через него Images. Они упоминают, что в документации виджетов изображений :
Все сетевые образы кэшируются независимо от заголовков HTTP.
BLOCKQUOTE>
6 ответов
Реляционная база данных не является Вашим лучшим предпочтительным вариантом для этого.
Почему?
Вы хотите, чтобы все Ваши редакторы передали изменения в Вашем плеере.
Ваш плеер - эффективно - сервер для всех тех редакторов. Вашему плееру нужны несколько открытых соединений. Это должно слушать все те соединения для изменений. Это должно отобразить те изменения.
Если изменения являются действительно большими, можно переместиться в гибридное решение, где редакторы сохраняют изменения и уведомляют плеер.
Так или иначе редакторы должны уведомить их плеер, что у них есть изменение. Это очень, намного более просто, чем плеер, пытающийся обнаружить изменения в базе данных.
Лучший дизайн является сервером, который принимает сообщения от редакторов, сохраняет их и уведомляет плеер. Этот сервер не является ни редактором, ни игроком, но просто брокером, который гарантирует, что все сообщения обрабатываются. Это принимает соединения от редакторов и игроков. Это управляет базой данных.
Существует две реализации. Сервер ЯВЛЯЕТСЯ плеером. Сервер является отдельным от игрока. Дизайн сервера не изменяется - только протокол. Когда сервер является плеером, затем сервер называет объекты плеера непосредственно. Когда сервер является отдельным от игрока, затем сервер пишет в сокет игрока.
Когда плеер является частью сервера, объекты плеера вызываются непосредственно, когда сообщение получено от редактора. Когда плеер является отдельным, маленький читатель собирает сообщения из сокета и называет объекты плеера.
Игрок соединяется с сервером и затем ожидает потока информации. Это может или быть введено от редакторов или ссылок на данные что сервер, сохраненный в базе данных.
Если Ваш трафик сообщений является достаточно маленьким так, чтобы сетевая задержка не была проблемой, редактор отправляет все данные на сервер/плеер. Если трафик сообщений является слишком большим, то редактор пишет в базу данных и отправляет сообщение только с базой данных FK к серверу/плееру.
Разъяснитесь, "Если редактор отказывает при уведомлении, плеер постоянно испорчен" в вопросе.
Это походит на плохой дизайн для сервиса плеера. Это не может быть "постоянно испорчено", если это не получает состояние от различных редакторов. Если это получает состояние от редакторов (но пытается зеркально отразить то состояние, например), затем, необходимо рассмотреть дизайн, где игрок просто получает состояние от редактора и не может быть "постоянно испорчен".
Просто откройте сокет между двумя процессами и сделайте, чтобы редактор сказал всем плеерам об обновлении.
Если бы это находится на той же машине, самый простой путь состоял бы в том, чтобы иметь именованный канал, "плеер" с блокированием чтения () и "редакторы", помещающие маркер в канал каждый раз, когда они изменяют DB.
Я думаю в этом случае, я сделал бы процесс для управления чтением-записями базы данных.
Каждый редактор, которые хотят сделать некоторые модификации к базе данных, звонит этому процессу, быть ею через IPC или сеть, или безотносительно метода.
Этот процесс может затем уведомить плеер изменения в базе данных. Плеер, когда он хочет получить некоторые данные, должен выполнить запрос данных, которые они хотят к процессу, управляющему базой данных. (Или процесс дб говорит это, в чем это нуждается, когда это уведомляет относительно изменения, таким образом, никакой запрос от необходимого игрока),
Выполнение этого будет иметь преимущество наличия только одного процесса, получающего доступ к DB SQLite, таким образом, никакая блокировка или проблемы параллелизма о базе данных.
Править: Я принимаю процессы на той же машине.
По-моему, существует два пути:
Опрос (поскольку Вы упомянули), но сохраняет его к единственному значению (как таблица, которая просто сохраняет LastUpdateTime других таблиц),
Используйте, какой бы ни межпроцессное взаимодействие там доступно на целевой платформе. Это могло быть событиями в Windows (например, в C# (я не знаю в Python), ManualResetEvent, AutoResetEvent или Взаимное исключение, если Вы хотите пожертвовать потоком официанта в каждом процессе), или Сигналы в Linux.
Сколько обрабатывает редактор (почему процессы?), и как часто Вы ожидаете обновления? Это не кажется, что хороший дизайн, особенно не рассматривая sqlite действительно не слишком доволен несколькими параллельными доступами к базе данных.
Если бы несколько процессов имеют смысл, и Вы хотите персистентность, вероятно, было бы более умно сделать, чтобы редакторы уведомили Ваш плеер через сокеты, каналы, общая память и т.п. и затем имели плеер (иначе, серверный процесс) делают сохранение.