Wersjonowanie - adnotacja Version

, , piątek, 9 kwietnia 2010 0 komentarze

Adnotacja Version specyfikuje pole lub właściwość typu wersja dla encji i służy jako wartość optymistycznego lokowania. Wersja jest używana w celu zapewnienia integralności w przypadku wykonywania operacji łączenia (merge) i kontroli współbieżności typu optymistycznego.

Reguły dotyczące pól / właściwości typu Version:
1. Jedynie jedna właściwość lub pole dla klasy może być oznaczona adnotacją Version.
2. Właściwość Vesion musi być mapowane do głównej tabeli dla klasy encji.
3. Właściwości typu Version nie powinny być aktualizowane bezpośrednio przez aplikację.
4. Pola następującego typu mogą być oznaczone przez Version: int, Integer, short, Short, long, Long, Timestamp
5. Operacje grupowe (bulk operations) nie respektują atrybutu Version. Tego typu operacje aktualizują poprostu wiersze w bazie danych, niezależnie od wartości wersji. Ponadto, zmiany wprowadzone przez aktualizacje nie są uwzględniane w encjach istniejących w kontekście persystencji.

Domyślne mapowanie dla pól i właściwości nie-relacyjnych

, , 0 komentarze

W przypadku pola lub właściwości innej niż właściwość relacyjna nie oznaczonej adnotacją mapującą zdefiniowaną w rozdziale 9 specyfikacji ejb-3_0-fr-spec-persistance (lub w przypadku braku odpowiadającej specyfikacji informacji mapującej w pliku deskryptora XML) stosowane są następujące reguły domyślnego mapowania:
• Jeżeli typ jest klasą, która jest oznaczona adnotacją Embeddable, następuje mapowanie w ten sam sposób jak w przypadku pola lub właściwości oznaczonej jako Embedded
• Jeżeli typ pola lub właściwości jest jednym z podanych, następuje mapowanie w ten sam sposób jak gdyby pole oznaczone było adnotacją Basic: prymitywne typy Java, wrappery na typy prymitywne, java.lang.String, java.math.BigInteger, java.math.BigDecimal, java.util.Date, java.util.Calendar, java.sql.Date, java.sql.Time, java.sql.Timestamp, byte[], Byte[], char[], Character[], enums, lub jakakolwiek klasa oznaczona jako Serializable.

W przypadku, gdy żadna z powyższych reguł nie zachodzi i pole lub właściwość nie zostało oznaczone żadną adnotacją zgłoszony zostanie błąd.

Klasy osadzone (Embeddable Classes)

, , 0 komentarze

Encja może używać innych drobnoziarnistych klas do reprezentowania jej stanu. Instancje tych klas, w przeciwieństwie do samych instancji encji nie posiadają identyfikatora persystencji. Zamiast tego, istnieją wyłącznie jako obiekty osadzone
w encji, do której należą. Takie osadzone obiekty należą wyłącznie do encji, w których zostały osadzone i nie są współdzielone z innymi encjami. Próba współdzielenia obiektów osadzonych w ramach encji ma niezdefiniowaną semantykę. Ponieważ takie obiekty nie mają persystentnej identyfikacji, są zwykle mapowane wspólnie z instancją encji, do której należą.

Klasy osadzone muszą być zgodne z wymaganiami dla encji określonymi w pkt 2.1 specyfikacji (ejb-3_0-fr-spec-persistance) z wyjątkiem takim że, klasy osadzone nie są oznaczone adnotacją Entity. Klasy osadzone muszą być oznaczone adnotacją Embeddable lub oznaczone jako takie w deskryptorze XML. Typ dostępu do osadzonego obiektu określa typ dostępu dla encji, w której obiekt jest osadzony. Specyfikacja wymaga obsługi tylko jednego poziomu osadzania.

Adnotacja Embeddable jest używana w celu specyfikacji klasy, której instancje są przechowywane jako nieodłączna część encji i współdzielą identyfikację z tą encją. Każda z perystentnych właściwości lub pól obiektu osadzonego jest mapowana do tabeli bazy danych odpowiadającej encji. Mapowane adnotacje Basic, Column, Lob, Temporal i Enumerated mogą być jedynie przenośnie użyte do mapowania pól lub właściwości persystentnych klasy oznaczonej jako Embeddable.

W celu specyfikacji pola lub właściwości encji, której wartość jest instancją klasy osadzonej należy użyć adnotacji Embedded. Adnotacje AttributeOverride i / lub AttributeOverrides mogą być użyte w celu przykrycia mapowania kolumn zadeklarowanych wewnątrz klasy osadzonej, które są mapowane do tabeli skojarzonej z encją. Nie jest wymagane od implementacji wsparcie dla obiektów osadzonych mapowanych na więcej niż jedną tabelę. Użycie adnotacji Embedded dla pola lub właściwości jest tożsame z użyciem pola lub właściwości klasy oznaczonej jako Embeddable.

Kontekst persystencji dla zarządzanego przez aplikację EntityManager-a

, , 0 komentarze

Kontekst persystencji (Persistence context) istnieje od momentu utworzenia Entity Manager-a przy użyciu metody EntityManagerFactory.createEntityManager do czasu zamknięcia Entity Manager-a, czyli do czasu wywołania metody EntityManager.close. Rozszerzony kontekst persystencji pobrany z Entity Manager-a zarządzanego przez aplikację jest niezależnym kontekstem persystencji to znaczy, że nie jest on propagowany wraz z transakcją.

Kontekst persystencji istnieje niezależnie od transakcji, jednakże zazwyczaj w tym samym czasie co transakcja. Entity Manager jest zwykle tworzony zaraz po rozpoczęciu transakcji, a kończy swoje działanie po powrocie z metody (lub w przypadku manager-a zarządzanego przez aplikację) po wywołaniu EntityManager.close.

Co to jest Mapped Superclass ?

, , 0 komentarze

Mapped Superclass oznacza klasę, dla której informacja o mapowaniu jest wprowadzana do encji, które z niej dziedziczą. Dla klasy tego typu nie ma zdefiniowanej oddzielnej tabeli. Klasa oznaczona adnotacją MappedSuperclass może zostać zmapowana w ten sam sposób jak encja z wyjątkiem tego, że wprowadzone mapowania będą miały znaczenie jedynie w jej podklasach. Takie zachowanie jest uwarunkowane tym, że dla klasy Mapped Superclass nie istnieje skojarzona tabela. W podklasach, odziedziczone z Mapped Superclass mapowania zostają wprowadzone w kontekście tabel zdefiniowanych dla tych podklas. Odziedziczone informacje o mapowaniu mogą zostać przykryte w takich podklasach przy użyciu adnotacji AttributeOverride i AssociationOverride lub odpowiadających im elementów z XML-a.

GlossyBlue Blogger by Black Quanta. Theme & Icons by N.Design Studio
Entries RSS Comments RSS