664 words

@Convert is not supported?

#1
2014-08-25 14:06

Does objectdb jpa implementation support @Convert annotation? (convertion of property before persistance and vice versa)

for example

@Convert(converter = MyConverter.class)
private Date date;

 

I've wrote a test on this, and seems that my Converters methods are not executed at all (like annotation doesent exist)

(source http://en.wikibooks.org/wiki/Java_Persistence/Basic_Attributes#Example_Converter ) 

vachagan
vachagan's picture
Joined on 2014-02-26
User Post #8
#2
2014-08-25 18:39

@Converter@Convert are new in JPA 2.1 and ObjectDB support of JPA 2.1 is not complete yet.

Particularly, this feature seems to be useful mainly in ORM for mapping Java types to RDBMS columns. What is the benefit of using it in an object database? Do you need it for queries? for any other reason?

We may support this feature, although it is mainly an ORM feature, if it is found to be useful with ObjectDB.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)
support
support's picture
Joined on 2010-05-03
User Post #2,027
#3
2014-09-01 08:47

I'll explain current problem (but I think this feature might be useful for other purposes I'm not aware of),

I have an Entity which has not much instances in database but it is essential for me that this entity is the same object whenever it is instantiated... Like concrete example is @Entity Currency, there are 100s of currencies but they are singletones and immutables... This is what i can achieve if i have abillity to perform some custom code when instantiating the object i can keep the cache and make sure that in any given time I have only one instance of same currency object...

 

To make those instances I've provided protected no arg constructor for ObjectDb so that only db can instantiate it, otherwhise I get instance through Factory method wich can ensure that it is a singletone...

 

Suppose I dont have this feature, (and L1 or L2 cache is not a guarantee that i'll get the same object) how would you implement such behaviour? How do I guarantee that any Currency instance is a singletone?

vachagan
vachagan's picture
Joined on 2014-02-26
User Post #9
#4
2014-09-01 19:57

You may try using a JPA lifecycle event (PostLoad).

The purpose of converters is totally different (i.e. mapping RDBMS columns to Java types).

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)
support
support's picture
Joined on 2010-05-03
User Post #2,029
#5
2014-09-02 06:06

Thanks for "JPA lifecycle event" I didn't know about this functionality.

But this wont help me to do what i've described above, there are some concrete reasons why I need same entity to be the same object in runtime, so far I didnt saw any solution to this... Maybe you could suggest something to do this?

I wonder that it seems i'm the only one ever needed to make entities singletone, (I cant make them an Enum, as those are not predefined and might be added dynamically), if I didnt explain the problem clear enough please let me know. 

This will actually help me avoid lot of useless code in the future, so I'd like to make sure there is no way to do this before I go through workaround way...

vachagan
vachagan's picture
Joined on 2014-02-26
User Post #10
#6
2014-09-05 14:30

Your need of 'singleton persistent objects' is clear.

You wrote: "This is what i can achieve if i have ability to perform some custom code when instantiating the object i can keep the cache and make sure that in any given time I have only one instance of same currency object..."

so this could be achieved by JPA lifecycle events.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)
support
support's picture
Joined on 2010-05-03
User Post #2,031
#7
2014-09-05 14:38

Yes but those methods are LIFECYCLE hooks, I have no way to influence instance state or creation of it... all methods are void something(//noarg) 

I can see no other option to achieve singletone instances... I really dont know if @Convert can have any other usecases but this is clearly one of them... And I believe not the bad one considering advantages when you use immutable singletones in java...

I guess I'll have to create a layer wrapping my repositories :(

P.S. if an entity B has a relationship to SingletoneEntity then it will actually instantiate it and not get singletone there... So its not possible to ensure all instances of SingletoneEntity to be singletone... this simply means that if I want it to be singletone i have to manually replace refrence in any other entity that has a relationship with the singltone one... meanwhile if DB did that before returning the reference I'd have no such problem

please correct me if i'm missing something (cos i have no other option than to write some shitcode)

vachagan
vachagan's picture
Joined on 2014-02-26
User Post #11

Post Reply

Please read carefully the posting instructions - before posting to the ObjectDB website.

  • You may have to disable pop up blocking in order to use the toolbar (e.g. in Chrome).
  • Use ctrl + right click to open the browser context menu in the editing area (e.g. for using a browser spell checker).
  • To insert formatted lines (e.g. Java code, stack trace) - select a style in the toolbar and then insert the text in the new created block.
  • Avoid overflow of published source code examples by breaking long lines.
  • You may mark in paragraph code words (e.g. class names) with the code style (can be applied by ctrl + D).
  • Long stack traces (> 50 lines) and complex source examples (> 100 lines) should be posted as attachments.
Attachments:
Maximum file size: 32 MB
Cancel