Нашето приложение прави разлика между данни за конкретен „потребител“ (всъщност юридическо лице, но ще го наричаме потребител за простота) и данни, които се споделят между всички потребители. Изискване е потребителските данни да се съхраняват в отделна схема за всеки потребител. Така че има данни, които са общи и споделени в схема, която може да бъде достъпна от всички потребители, и редица схеми, всяка от които може да бъде достъпна само от потребителя, за когото се отнася. Всяка от тези потребителски схеми ще съдържа един и същ набор от таблици, така че може да имаме нещо като USERA.ACCOUNT, USERB.ACCOUNT (и т.н.) и SHARED.PRODUCT в общата схема. Постигнахме това и създадохме нещо, което отговаря доста добре на изискванията, като посочихме @Table(schema="SHARED") за типовете обекти, представляващи общи данни. Ние не уточняваме схемата за типовете обекти „потребител“ – изборът на схема, в която да се търси, е оставен на DAO. Имаме един DAO на потребител, всеки конфигуриран да използва подходящата потребителска схема и избран въз основа на потребителския „контекст“, свързан с дадена операция.
Дотук добре - но името на споделената схема вече е твърдо кодирано във файловете на класа на обекта за споделените типове данни. И тъй като е в анотация, той се компилира в тях. Това не е добре за нас, тъй като обикновено при внедряване на клиентски сайтове откриваме, че клиентският DBA желае да диктува имената на схемите, но ние не желаем да се налага да прекомпилираме, за да постигнем това. Дори по-лошо, на клиентски сайт обикновено имаме множество системи за различни цели с различни имена на схеми (PROD, UAT и т.н. и т.н.) и да правим това с помощта на множество прекомпилирани копия на една и съща система би било лудост.
Не можах да намеря начин да отменя схемата, дефинирана в анотацията. Някой знае ли начин за постигане на това? Опитах се да пренеса нашата система от директно използване на хибернация (SessionFactory и т.н.) към JPA (EntityManagers и т.н.), тъй като това по принцип позволява атрибутът на схемата в анотацията да бъде заменен от запис в ORM.xml, но изглежда има свят на проблеми с използването на JPA/JTA/Spring, при което операциите в жизнения цикъл на транзакцията, като флъш, вече не се случват, както бихте очаквали, така че аз се отказах от това.
Всякакви предложения ще бъдат добре дошли...
