Вы, похоже, спрашиваете, можно ли динамически определять регион во время выполнения на основе запроса, например из Spring [Web] @Controller?
Возможно, что-то вроде что было запрошено в PR # 91 ? Хотя я отказался от этого PR в пользу более гибкого подхода, имя DATAGEODE-244 - " Добавить интерфейс RegionResolver для включения отложенного разрешения области, когда и где это необходимо. "
Хотя, ваш вопрос немного двусмысленный, и я не хочу здесь ничего предполагать.
Несколько моментов ...
1) Во-первых, верно, что приложение объект домена (например, GeneralData или Employee) сохраняется до определенного c, явно объявленного Region по отношению к " mapping " (то есть с использованием SDG @Region " mapping"аннотация), как разрешено Spring Data Репозиторий абстракция. На самом деле это ничем не отличается от любой другой технологии отображения (например, ORM; JPA использует Hibernate).
По умолчанию, если аннотация отображения @Region не указана, тогда SD [G] будет использовать простое имя класса для типа объекта домена приложения (например, «Сотрудник») для разрешения области, в которой объект будет сохранен. Как правило, всегда лучше быть явным и объявить свои намерения с помощью аннотаций сопоставления Spring Data [GemFire] (например, @Region или @Id для обозначения идентификатора и т. Д. c) .
2) Во-вторых, конечно, все это зависит от того, используете ли вы в первую очередь инфраструктуру репозитория Spring Data [GemFire] . Если нет, то вышеупомянутый пункт является спорным. Если да, то я думаю, что вы хотите что-то вроде этого ...
@Region("Employees")
class Employee { ... }
@Controller
class MyController {
@Autowired
private EmployeeRepository employeeRepository;
@PostMapping("/employees")
public String process(Employee employee) {
// modify employee, then save...
if (employee.isContractor()) {
// save to "Contractors" Region
}
else {
employeeRepository.save(employee);
}
}
}
Конечно, вы не можете использовать EmployeeRepository для сохранения объекта Employee (который отображается в область «Сотрудники» для Регион «Контрагенты» с заданным типом Employee «сопоставляется» с Регионом «Сотрудники» с помощью аннотации отображения «@Region».
SDG действительно добавляет поддержку иногда go теперь позволяет пользователям аннотировать интерфейс Repository с помощью аннотации сопоставления @Region, например ...
@Region("Contractors")
interface ContractorRepository extends CrudRepository<Employee, Long> { ... }
Это будет эффективно переопределять аннотацию сопоставления @Region для типа объекта домена приложения (например, Employee) и использовать вместо этого аннотацию сопоставления @Region в Репо. Это позволило пользователям иметь разные декларации репозитория (интерфейса) для одного и того же типа объекта домена приложения для сопоставления объекта домена с различными регионами.
Тем не менее, это довольно громоздко, если у вас много разных регионов и динамических c logi c, основанных на запросах, чтобы иметь репозиторий объявление face для каждого потенциального получателя.
В качестве альтернативы вы можете зарегистрировать другой Spring HttpMessageConverters в вашей конфигурации Spring Web MVC, чтобы преобразовать данные запроса в тип (сущности) (например, Contractor), который определяет его постоянное назначение, в зависимости от того, куда принадлежат данные.
@Region("Contractors")
class Contractor extends Employee { ... }
Затем:
@PostMapping("/employees")
public void process(Contractor contractor) {
// modify contractor, then save...
this.employeeRepository.save(contractor);
}
3) В-третьих, если вы не используете репозиторий данных Spring абстракция (и расширение SDG), тогда вы можете больше контролировать, где хранятся данные, используя GemfireTemplate.
Например:
@Region("Employees")
class Employee { .. }
@Region("Contractors")
class Contractor extends Employee { ... }
@Configuration
@ClientCacheApplication
class GemFireConfiguration {
@Bean("Employees")
ClientRegionFactoryBean employeesRegion(ClientCache clientCache) { ... }
@Bean("Contractors")
ClientRegionFactoryBean contractorsRegion(ClientCache clientCache) { ... }
@Bean("employeesTemplate) {
GemfireTemplate employeesTemplate(ClientCache clientCache) {
return new GemfireTemplate(clientCache.getRegion("/Employees"));
}
@Bean("contractorsTemplate) {
GemfireTemplate contractorsTemplate(ClientCache clientCache) {
return new GemfireTemplate(clientCache.getRegion("/Contractors"));
}
}
@Controller
class MyController {
@Autowired
@Qualifier("employeeTemplate")
private GemfireTemplate employeesTemplate;
@Autowired
@Qualifier("contractorsTemplate")
private GemfireTemplate contractorsTemplate;
@PostMapping("/employees")
public void process(Employee employee) {
// modify the employee, then save...
if (employee.isContractor()) {
constractorsTemplate.put(employee.getId(), employee);
else {
employeesTemplate.put(employee.getId(), employee);
}
}
}
Конечно, вы возможно, придумал бы более творческий способ «решить», какой шаблон нужен на основе запроса, используя шаблон «Стратегия» или аналогичный эффект.
Если я правильно понимаю ваш U C, тогда DATAGEODE -244 должен обеспечить некоторое облегчение в ближайшем будущем, как только оно будет расставлено по приоритетам относительно другой текущей работы (довольно скоро, на самом деле).
Я скажу, что я Я на самом деле не фанат динамического изменения постоянного местоположения в зависимости от типа запроса. Каждая сущность тщательно продумана, чтобы быть сопоставленной с указанным c целевым, постоянным хранилищем.
Кроме того, здесь не так (по крайней мере, я так думаю), я также не фанат "JUNK" Регионы, т.е. Регионы, в которых хранится несколько «типов» данных. Это менее чем оптимально для запросов, что может быть 1 аргументом, почему вы хотите сохранить один тип домена приложения для разных регионов, так как эти регионы могут быть настроены для разных типов запросов (с индексами) и / или событий.
В любом случае, надеюсь, что в этом ответе будут какие-то указания или идеи, пока DATAGEODE-244 не будет готов.
Приветствия!