Réplication de 2 BD distantes vers une seule BD PouchDB pour contourner la restriction de la BD Android 1

Question

J'ai une application 3 PouchDB ionique qui fonctionne sur certains appareils Android (par exemple 4.4 & 5.0) mais pas sur d'autres (par exemple 7.0.1). Cela fonctionne sur tous les iPhones! Je suppose que cela est dû à certaines versions d'Android limitant le nombre de DB Webview à un par application. J'ai lu que l'on peut contourner cela en utilisant SQLite mais SQLite est beaucoup plus lent et est particulièrement lent pour les documents DB contenant des images (ce que j'ai). Je voudrais donc replacer mes deux bases de données CouchDB dans une seule base de données PouchDB.

J'ai quelques questions:

1. Y at-il des raisons pour lesquelles cela ne fonctionnerait pas comme un moyen de contourner la limite DB Android? Je vais avoir un localDB.replicate.from(remoteDB) pour chacun de mes deux DB distants (appelés 'news' & 'events').
2. Actuellement, chacune de mes bases de données CouchDB a des documents avec des ID tels que: 2017-1 et 2017-12 pour le premier et le dernier mois de 2017. Si les deux bases de données se répliquent dans PouchDB, devront-elles avoir des ID uniques? Sinon, comment pourrais-je différencier?

Answer 1

1. Oui, vous pouvez répliquer autant dbs dans un DB que vous le souhaitez, mais les documents avec le même identifiant doit être "eventual conflicts" lorsque répliqué dans un db, donc un document perdre et être visibles dans la fusionné db en demandant explicitement des conflits. Lorsque vous utilisez des identifiants non aléatoires, vous devez mettre à jour au moins un de vos dbs pour utiliser un espace de noms unique, par exemple Event-2017-01. Cela simplifiera également le filtre de réplication dont vous auriez besoin si vous souhaitez implémenter la réplication bidirectionnelle avec les dbs distants encore séparés.

Je donne habituellement les pièces jointes d'un doc doc un séparé qui est préfixé, i.e.: attachment-[orig_id] si les médias peuvent être filtrés de réplications. Vous pouvez envisager de résoudre les pièces jointes de cette façon (pour au moins un des dbs) de sorte que vous pouvez mélanger toutes les pièces jointes dans un db "media" avec l'adaptateur idéal pour le client donné et utiliser d'autres adaptateurs pour les documents normaux.

Ainsi, par exemple, vous pouvez avoir:

mdb = new Pouchdb('media', {adapter:'idb'}). 
     replicate.from('http...news', {filter:'_view', view:'mediadocs'}). 
     replicate.from('http...events', ...filter...); 
    news = new Pouchdb('news', {adapter:'websql'}). 
     replicate.from('http...news', {filter:'_view', view:'normaldocs'}); 
    events = new Pouchdb('events', {adapter:'websql'}). 
     replicate.from('http...events', {filter:'_view', view:'normaldocs'}); 

Si les champs avec les médias sont divisés en un autre document sur la base du document original vous n'avez pas encore des copies redondantes .. Mais vous pouvez construire dbs temporaires nourris des nouvelles et des événements:

today = new Pouchdb('today', {adapter:'memory'}). 
     replicate.from(news, {selector ..dayview..}). 
     replicate.from(events, ...selector...); 

où les bases de données temporaires utilisent relativement peu de ressources, mais leurs documents servent d'index aux documents multimédias db correspondants.