-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple collections share sockets and peers when replicationWebrtc is used for synchronization #5926
base: master
Are you sure you want to change the base?
Conversation
You can experience the difference between before and after modification at this link https://stackblitz.com/~/github.com/croatialu/rxdb-replication-webrtc |
Solution: Use closure to save data such as peers and sockets, and then each replicationWebrtc will try its best to reuse existing peers and sockets How to use: const creator = getConnectionHandlerSimplePeer({})
// ^ create a creator
Object.keys(database.collections).map(async (key) => {
return replicateWebRTC({
collection:
database.collections[key as keyof typeof database.collections],
connectionHandlerCreator: creator,
// ^ use the creator
topic: dbName,
pull: {},
push: {},
})
})
|
Hi @croatialu |
Okay, I'll take care of it right away. Thanks for the reminder! |
2ca0a7a
to
6927db5
Compare
rxdb/test/unit/replication-webrtc.test.ts Lines 161 to 162 in 48ea5ee
I found that this piece of code for the unit test uses data synchronization between collections of different names in the same database. My idea is to synchronize collections of the same name from different databases. My solution:
The problem that the solution wants to solve is that the same collection data is synchronized on different ends. So in an existing unit test, two different collectionnames cannot synchronize data. Without modifying the unit tests, it didn't occur to me that different Collection synchronization schemes locally could also support the same Collection synchronization scheme between different ends To pass the unit test, it will involve modifying the existing unit test method (changing to a different database with the same collectionName), which is likely to cause break change. Do you have a better idea about that. @pubkey translate by youdao |
This PR contains:
Describe the problem you have without this PR
#5925