Je n'ai peut-être pas été clair : je faisais de façon sous-entendue la comparaison CoreData/Realm.
Je ne vois pas le rapport. Tant que les objets sont basés sur NSObject (il me semble que c'est le cas avec Realm), on peut binder dessus et utiliser NSArrayController.
Je n'ai pas poussé le questionnement très loin mais j'ai eu l'impression que pour changer les valeurs d'une property d'un objet Realm il fallait "ouvrir un commit", changer la valeur, puis "fermer le commit". C'est ce qui me fait dire que ce n'est pas compatible avec les bindings.
Quant aux ArrayController, tu as la possibilité d'en avoir un qui te liste tous les instances d'une entité Core Data donnée.
Pour l'équivalent de NSPersistentDocument, si c'est si facile à faire, pourquoi ne livrent-ils pas une classe adéquate ?
Je n'ai pas poussé le questionnement très loin mais j'ai eu l'impression que pour changer les valeurs d'une property d'un objet Realm il fallait "ouvrir un commit", changer la valeur, puis "fermer le commit". C'est ce qui me fait dire que ce n'est pas compatible avec les bindings.
Effectivement, mais sur un objet géré par Realm, tu peux avoir des propriétés qui seront stockées dans la base Realm et d'autres, non. Donc tu peux te faire des propriétés/accesseurs qui encapsulent le positionnement de la propriété stockée.
En revanche, d'après mon expérience cela peut-être problématique de faire beaucoup de petites transactions. Cela fait grossir la base plus vite et sur iOS (pas trop sûr avec macOS), il y a une taille maximum de la base de donnée qui assez basse (~200 Mo je crois) à cause d'une limite de la fonction système mmap.
Sur une app, je faisais un import de nombreux petits objets en tâche de fond GCD et en parallèle, je permettais à l'utilisateur de "sélectionner" ces objets. J'avais donc des transactions en multi-tâche. Comme les transactions sont exclusives/bloquantes (il ne peut y en avoir qu'une seule à la fois), je ne pouvais pas faire une seule grosse transaction pour l'import et du coup, je faisais beaucoup de petites transactions pour ne pas bloquer l'UI et j'atteignais la limite de taille de la base assez vite.
Je compte stocker des Strings entrés via un NSTextField, je pensais sauver la base à chaque appel de textDidChange... mais ton retour me dissuade. Je crois que je vais rester sur CoreData...
La solution pour l'instant c'est de faire un compactage de temps en temps (voir deuxième lien). Tu peux faire ce que tu décris si à la fin de la saisie du formulaire, tu compactes la base.
Je ne suis pas certain d'avoir tout compris, mais je crois que le problème est lié à la combinaison de multiples transactions et de parallélisme. Donc si tu travailles uniquement dans le thread principal, tu n'auras sans doute pas le problème.
Effectivement, mais sur un objet géré par Realm, tu peux avoir des propriétés qui seront stockées dans la base Realm et d'autres, non. Donc tu peux te faire des propriétés/accesseurs qui encapsulent le positionnement de la propriété stockée.
Juste pour être sûr, ton idée c'est d'overrider les setter des propriétés persistantes pour les encadrer par des beginCommit et endCommit ?
Juste pour être sûr, ton idée c'est d'overrider les setter des propriétés persistantes pour les encadrer par des beginCommit et endCommit ?
Non en fait, tu déclares des propriétés non persistantes qui serviront à encapsuler les propriétés persistantes (qu'il ne faudra pas utiliser directement bien-sûr).
Je ne sais pas si ton code fonctionne avec les RLMObject car j'ignore par quel moyen Realm s'interface avec les propriétés des objets.
Le truc c'est que je n'ai travaillé qu'en Swift avec Realm et donc je n'avais pas d'ivar.
J'ai dû créé une variable pour la persistence et une property pour l'accès.
J'aurais dû faire un exemple en swift...
Ce que je voulais montrer, c'est surtout l'existence des "ignoredProperties" qui permettent d'avoir des propriétés qui ne sont pas persistentes pour encapsuler des traitements sur les données persistentes.
PS:
Je ne fais pas de java, ni de javascript (dieu merci) mais du C#, Objective-C et Swift et je confond tous les langages sans arrêt. Je laisse l'éditeur et le compilateur me corriger.
Je connais mal Swift, mais j'aurai été tenté (sans iVar) d'ouvrir le commit dans willSet et de le fermer dans didSet. De mémoire je crois qu'il y a des méthodes dans Realm pour juste ouvrir le commit et juste le fermer.
Ton approche avec les propriétés ignorées serait utile (j'imagine) si l'on ne commit qu'à certains moments (avant un save, lorsqu'on le change de VC, etc.) et non pas lors de chaque - textDidChange
Pour le langage, je faisais référence à this au lieu de self ;-)
Pour le langage, je faisais référence à this au lieu de self ;-)
J'avais saisi C'est à cause du C#...
J'ai utilisé le même principe pour pouvoir déclarer des données membres de type enum Swift.
var _providerType:Int
var providerType:ProviderType
{
get {
return ProviderType(rawValue:_providerType)!
}
set (value) {
_providerType = value.rawValue
}
}
Réponses
Je n'ai peut-être pas été clair : je faisais de façon sous-entendue la comparaison CoreData/Realm.
Je n'ai pas poussé le questionnement très loin mais j'ai eu l'impression que pour changer les valeurs d'une property d'un objet Realm il fallait "ouvrir un commit", changer la valeur, puis "fermer le commit". C'est ce qui me fait dire que ce n'est pas compatible avec les bindings.
Quant aux ArrayController, tu as la possibilité d'en avoir un qui te liste tous les instances d'une entité Core Data donnée.
Pour l'équivalent de NSPersistentDocument, si c'est si facile à faire, pourquoi ne livrent-ils pas une classe adéquate ?
Effectivement, mais sur un objet géré par Realm, tu peux avoir des propriétés qui seront stockées dans la base Realm et d'autres, non. Donc tu peux te faire des propriétés/accesseurs qui encapsulent le positionnement de la propriété stockée.
En revanche, d'après mon expérience cela peut-être problématique de faire beaucoup de petites transactions. Cela fait grossir la base plus vite et sur iOS (pas trop sûr avec macOS), il y a une taille maximum de la base de donnée qui assez basse (~200 Mo je crois) à cause d'une limite de la fonction système mmap.
Sur une app, je faisais un import de nombreux petits objets en tâche de fond GCD et en parallèle, je permettais à l'utilisateur de "sélectionner" ces objets. J'avais donc des transactions en multi-tâche.
Comme les transactions sont exclusives/bloquantes (il ne peut y en avoir qu'une seule à la fois), je ne pouvais pas faire une seule grosse transaction pour l'import et du coup, je faisais beaucoup de petites transactions pour ne pas bloquer l'UI et j'atteignais la limite de taille de la base assez vite.
Intéressant... en as-tu parlé aux devs de Realm ?
Je compte stocker des Strings entrés via un NSTextField, je pensais sauver la base à chaque appel de textDidChange... mais ton retour me dissuade. Je crois que je vais rester sur CoreData...
Non, car le problème est connu.
Par exemple:
https://github.com/realm/realm-cocoa/issues/4229
ou dans la doc:
https://realm.io/docs/swift/latest/#file-size--tracking-of-intermediate-versions
La solution pour l'instant c'est de faire un compactage de temps en temps (voir deuxième lien).
Tu peux faire ce que tu décris si à la fin de la saisie du formulaire, tu compactes la base.
Je ne suis pas certain d'avoir tout compris, mais je crois que le problème est lié à la combinaison de multiples transactions et de parallélisme. Donc si tu travailles uniquement dans le thread principal, tu n'auras sans doute pas le problème.
Juste pour être sûr, ton idée c'est d'overrider les setter des propriétés persistantes pour les encadrer par des beginCommit et endCommit ?
Non en fait, tu déclares des propriétés non persistantes qui serviront à encapsuler les propriétés persistantes (qu'il ne faudra pas utiliser directement bien-sûr).
Bon, le problème de cette méthode c'est d'avoir un pointeur vers l'objet Realm.
D'autant qu'un objet Realm ne peut pas être utilisé d'un thread à l'autre.
Quel est l'avantage par rapport à
?
PS : tu fais du Java en ce moment ou du Javascript
?
Je ne sais pas si ton code fonctionne avec les RLMObject car j'ignore par quel moyen Realm s'interface avec les propriétés des objets.
Le truc c'est que je n'ai travaillé qu'en Swift avec Realm et donc je n'avais pas d'ivar.
J'ai dû créé une variable pour la persistence et une property pour l'accès.
J'aurais dû faire un exemple en swift...
Ce que je voulais montrer, c'est surtout l'existence des "ignoredProperties" qui permettent d'avoir des propriétés qui ne sont pas persistentes pour encapsuler des traitements sur les données persistentes.
PS:
Je ne fais pas de java, ni de javascript (dieu merci) mais du C#, Objective-C et Swift et je confond tous les langages sans arrêt. Je laisse l'éditeur et le compilateur me corriger.
OK.
Je connais mal Swift, mais j'aurai été tenté (sans iVar) d'ouvrir le commit dans willSet et de le fermer dans didSet. De mémoire je crois qu'il y a des méthodes dans Realm pour juste ouvrir le commit et juste le fermer.
Ton approche avec les propriétés ignorées serait utile (j'imagine) si l'on ne commit qu'à certains moments (avant un save, lorsqu'on le change de VC, etc.) et non pas lors de chaque - textDidChange
Pour le langage, je faisais référence à this au lieu de self ;-)
En tous cas merci pour ton retour !
Oui, beginWrite, commitWrite.
J'avais saisi
J'ai utilisé le même principe pour pouvoir déclarer des données membres de type enum Swift.