django数据库同步供离线使用

发布于 2024-11-26 16:57:47 字数 272 浏览 4 评论 0原文

我有一台主 django 服务器,用于存储数据(mysql 数据库)。

在线:我希望许多用户在他们的笔记本电脑(sqlLite DB)上同步此数据库的副本(仅必须复制增量)

离线(用户无权访问主服务器):用户可以查看和更新​​其本地数据库。

返回在线:用户笔记本电脑上的修改内容会同步回主 django 服务器。

我认为,由于我有两种数据库,我需要在 django 对象级别进行同步。 有 django 应用程序可以做到这一点吗? 如果没有,您将如何编写这样的功能?

I have one master django sever where the data are stored (mysql database).

Online : I would like many users to have a copy from this database synchronized (only delta's must be copied) on their laptops (sqlLite DB)

Offline (users do not have access to the master server) : users can view and update their local database.

Back to Online : what has been modified on users laptops is synchronized back to the master django server.

I think,as I have 2 kind of database, I need to synchronize at django object level.
Is there a django application doing that ?
If not, how will you procced to code such a feature ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

彩虹直至黑白 2024-12-03 16:57:47

事实证明我正在 Django 中运行这样的系统。

这不是一个完整的答案,只是当前正在解决(大部分)问题的答案。

  • 使用 UUID 作为主键。这大大减少了不同对象的主键冲突。
  • 使用 Django 的序列化框架进行数据交换。中央管理站点可以选择将更改列表中选定的对象下载到 Django 兼容的序列化文件中。然后,用户可以离线并启动本地管理站点,然后上传序列化文件。当完成离线版本时,使用相同的过程,在“离线”管理站点中,对象被序列化到文件,并上传到中央管理站点。
  • 序列化框架非常有用,因为您可以获取实际的(未保存的)对象,然后决定是否保存它,并在保存之前修改一些字段。

我们在使用这个简单的系统时遇到了很少的麻烦,而且由于内容被正确分类并且编辑器仅创建/编辑一组不重叠的类别,因此也有所帮助。

我已经与一些人讨论过这个问题,并向我提出了几种解决方案:

  • 使用时间戳字段:这有助于决定保存哪个版本和丢弃哪个版本。
  • 使用版本字段,其中包含主版本号和次版本号。次要编辑(例如拼写更正)仅更新次要版本号,而重大更改会更新主要版本号并将次要版本号设置为 0。这样,在比较时您始终知道哪个版本具有更高的优先级。然而,这需要对编辑用户进行教育和约定。
  • 对象更新。一个单独的模型,存储来自离线编辑的更新。然后,“主要”编辑器将它们合并到实际对象中,并帮助使用一些额外的管理视图来查看差异(使用 google-diff-match-patch 等)。还可以将对象标记为允许直接更新,即不存储更新并在到达时直接应用它们。不便的是“主”编辑必须审查所有更新,这取决于更新了多少信息。

希望这能在某种程度上有所帮助。如果有人决定实施其中的某些内容,我很乐意听取他的意见。

Turns out that I'm running a system like this in Django.

This is not a complete answer, just the answer that is currently solving (mostly) the problem.

  • Use of UUIDs for primary keys. That decreases greatly primary keys collision for diferent objects.
  • Use Django's serialization framework for data interchange. The central admin site has an option to download the selected objects in the changelist to a Django-compatible serialized file. Then the user can go offline and start a local admin site, and there, upload the serialized file. When finished offline edition, the same process is used, in the "offline" admin site the objects are serialized to a file, and the uploaded to the central admin site.
  • The serialization frameworks is very useful, since you can get an actual (and unsaved) object, then decide to save it or not, and to modify some fields before the save.

We have run into very little trouble with this simple system, also helped since the content is properly categorized and the editors only create/edit a non overlapped set of categories.

I have talked with this with some people, and proposed me several solutions:

  • Use an timestamp field: That help decide which version to save and one to discard.
  • Use a version fields, with mayor and minor version numbers. Minor editing (like spelling corrections) only updates the minor version number, and major changes updates the mayor version number and sets the minor to 0. That way when comparing you always know which one gets higher priority. However this needs education and conventions within the editing users.
  • Object updates. A separate model, which stores updates coming from offline edits. Then a 'chief' editor merges them into the actual object, helped with some additional admin views to view differences (using google-diff-match-patch and the like). An object can also be flagged to allow direct updates, that is, no storing updates and apply them directly on arrival. The inconvenience is the 'chief' editor has to review the all the updates, and that depends on how much information get updated.

Hope this helps in some way. If anyone decides to implement something of this, I'll love to hear from him.

‘画卷フ 2024-12-03 16:57:47

我构建了一个 Django 应用程序来执行此操作。当在应用程序的远程/笔记本电脑版本上创建模型实例时,它们会被标记为脏并获得临时 ID。远程应用程序定期检查与主服务器的连接。当有网络连接时,即应用程序在线时,它会从主服务器获取每个新脏模型实例的永久 ID。临时 id 被替换为永久 id,然后脏实例被同步到 master。

我使用 Django REST 框架来接收和更新主服务器上的脏模型实例。

请注意,这还需要在离线计算机上运行本地 Web 服务器。为此我选择了 CherryPy。

I built a Django app which does this. When model instances are created on the remote/laptop version of the app they are marked as dirty and get a temporary id. The remote app checks regularly for connectivity to the master server. When there is a network connection, i.e. the app is online, it gets a permanent id for each new dirty model instance from the master server. The temporary ids are replaced with permanent ids and then the dirty instances are synchronized to the master.

I used the Django REST framework to receive and update the dirty model instances on the master server.

Note that this also requires running a local web server on the offline computer. I chose CherryPy for that.

酷炫老祖宗 2024-12-03 16:57:47

好吧,我实际上不知道是否有一个 django 应用程序可以做到这一点,但我会这样进行:

为“offline_update”创建一个方法:连接到服务器的数据库,选择 id 与本地中的 id 匹配的所有对象数据库。您更新本地数据库。然后选择其余条目,并将它们添加到本地数据库,

为“online_update”创建一个方法,与相同的例程相反。

优点:易于实现(Objects.all() 获取所有内容,然后操作和更新,或直接保存)

缺点:竞争条件(如果 2 个用户更新同一个条目(不一定在同一时间)会怎样?谁拥有最新的一个?)

你基本上创建了一种“mysql-svn”来保持两个数据库的更新。

我对你的问题投+1,因为它真的很有趣。我一直通过转储数据库(通过 mysql)然后加载到本地数据库来工作。不使用 django。

Well, I actually don't know if there's a django app to do that, but I will proceed like this:

create a method for "offline_update": connection to the server's database, you select all objects whose id matches the one in the local database. you update the local database. then you select the rest of the entries, and you add them to local database

create a method for "online_update" the same routine, inverted.

PRO: easy to implement (Objects.all() gets you everything, then you manipulate and update, or save directly)

CONS: race conditions (what if 2 users update the same entry (not necessarily on the same time)? who's got the most updated one?)

you basically create a sort of "mysql-svn" to keep the 2 databases updated.

I'm voting +1 to your question, because it's really interesting. I've always worked by dumping the database (via mysql) and then loading into the local database. without using django.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文