Nous essayons de créer deux référentiels Gemfire, Puisqu'il existe deux objets bean différents, mais que nous voulons stocker ces deux objets bean dans la même région gemfire.Est-il possible de stocker deux objets bean sur la même région Gemfire?
Est-ce une bonne façon de le faire? Si "Oui" alors Comment le faire?
Merci d'avance.
... nous voulons stocker ces deux objets bean dans la même région gemfire. Est-ce une bonne façon de le faire?
C'est discutable. Cependant, cela dépend vraiment des exigences de votre application et des cas d'utilisation. Cela dépend aussi de la relation entre les objets.
Par exemple, si vous avez un Customer qui s'étend (est-a) Person puis le stockage à la fois Customers et People dans la même région peut sembler pas si mal.
Mais, si vous stockez Customers et dites Purchases, où un Customer est composé, ou « a-un » Set/Liste des Purchases, alors qui est plus difficile à digérer. Cela rend également plus difficile l'interrogation de cette région puisque le moteur de requête (OQL) inspecte les informations de type d'objet pour les propriétés/champs, même les invocations de méthodes si invoquées dans la requête, ce qui peut conduire à ClassCastExceptions et NoSuch[Method|Field]Exceptions. Donc sois prudent. J'ai tendance à être plus puriste à cet égard et suggère/recommande que vous gardiez les objets du modèle de domaine d'application dans des régions séparées, en particulier dans le cas de relation "has-a". Il est possible de stocker les données dans des régions distinctes tout en "colocalisant" les données (c'est-à-dire les régions), en particulier à des fins d'interrogation. Voir here pour plus de détails.
Mais ...
Tout cela ne veut pas dire que vous ne pouvez pas obtenir stocker des objets de types similaires, ou même différents, dans la même région.
En règle générale, vous annoter votre entreprise, domaine d'application des objets avec l'annotation @Region pour spécifier le cache GemFire région l'objet sera stocké dans, comme si ...
@Region("Customers")
class Customer extends Person { ... }
@Region("Purchases")
class Purchase { ... }
pour définir votre référentiels ...
interface CustomerRepository extends GemfireRepository<Customer, Long> { .. }
interface PurchaseRepository extends GemfireRepository<Purchase, Long> { .. }
Normalement, lorsque l'extension du référentiel de l'infrastructure du référentiel communes SD et SD GemFire détecte les interfaces du référentiel, il inspecte les paramètres de type, les objets voit domaine d'application (c.-à-Customer & Purchase), inspecte ceux-ci et déterminer des régions dans laquelle chaque objet de domaine d'application appartient par ...
Soit la détection et l'inspection de la valeur d'attribut d'annotation @Region, ou ..
Utilisation de la " simple "nom du nom de la classe d'objet du domaine en tant que nom de la région (c.-à-d. Région "Client" de l'objet domaine Customer).
Cela détermine la région.
Cependant, si vous voulez que les deux Customer et Purchase objets à ranger dans la région SAME, puis étend SD GemFire l'infrastructure commune de dépôt et vous permet d'annoter vos interfaces du référentiel avec l'annotation @Region, comme si ...
@Region("Customers")
interface CustomerRepository extends GemfireRepository<Customer, Long> { .. }
@Region("Customers")
interface PurchaseRepository extends GemfireRepository<Purchase, Long> { .. }
dans ce cas, les deux objets Customer et Purchase seront stockés dans la région « clients » depuis l'annotation @Region sur les interfaces du référentiel surclassent l'annotation @Region sur l'objet de domaine d'application individuelle s.
Il y avait des raisons valables et des cas d'utilisation pour autoriser cette fonctionnalité spécifiquement dans Spring Data GemFire. Pour plus d'informations à ce sujet, lisez here.
Quelle que soit l'approche adoptée, vous devriez peser soigneusement vos options.
Espérons que cela aide!
Cheers, John