>My question is.. how is data stored? When I store an entity that
refers to the User entity, then go into mysql and do a desc tableName, I
see a BLOB type that refers to the User entity reference.
I am assuming you are using JPA entities. Did you annotate your
relationships with @Oneto../_at_ManyTo.. ? Go through JPA portion of
JavaEE tutorial to get started with this.
On 6/18/2010 1:53 PM, glassfish_at_javadesktop.org wrote:
> Hi all,
>
> Not sure if this is the right place to post this.
>
> I've been playing around with EJB 3.1 with Glassfish v3. I have a couple of entity simple entity beans that do work, but I am trying to find out a bit more about how they are stored in the database (and/or why).
>
> Primarily, I have a User entity, and then other entities that refer to the User entity. Pre-entity beans, I'd set up a simple table with a long or integer value to store the User ID reference, then do some simple select query that joins the two tables. EJb 3.x brought in the nice ability to refer to an actual entity class from within another to set up the join for you. It works.. just fine.
>
> My question is.. how is data stored? When I store an entity that refers to the User entity, then go into mysql and do a desc tableName, I see a BLOB type that refers to the User entity reference. I would have expected to see a long/integer of some sort to just be a point to the User table ID field (or index field). When I do a query after i've inserted some data, the entity table outputs a huge gob of data for a single row, including I see stuff like my java import statements in the database table? My only guess is that it is serializing the entity bean into the BLOB field instead of a much simpler/faster ID pointer.
>
> Is this what is happening? If so, isn't that a HUGE waste of storage space? I know storage is cheap now, but it seems really odd to me that it would serialize the entire java object inot a BLOB field.
>
> I tell you what bothers me more.. when I manually go through the table, I can't see a nice simple query from the mysql command line. The BLOB field, with data in it, distorts the dang row, and thus I don't get a nice set of columns of data + rows, it's impossible to read. More so, it's even harder to do any sort of manual SQL insert for dummy data while testing/developing. I have no idea how I can create a pointer to a User entity table from another table that refers to it. The only way I've been able to do this is create some code that creates dummy entity objects and then stores those.
>
> So.. assuming someone replies with "yes..that is what happens.. that is the pros and cons of using entity beans in this way..", my question then is, is there any "bad" reason to just avoid using object references in my entity beans and instead i'll put in the Long value and set up the named SQL queries and such myself? In my stateless session bean for example, I can put in the User ID directly in to the Long ID field of another entity and then still call the EM methods to store/flush the entity data?
>
> I am not opposed to doing a little extra work to keep the DB slim and fast. I understand to some extent the benefits of using the entity beans in this way.. but I am questioning if the speed is as good with having to deserialize objects from the BLOB fields as opposed to a join on a table based on the ID field. As well, the amount of storage that will be required for every object...especially complex objects with many nested levels of data.
>
> Thanks.
> [Message sent by forum member 'andjarnic']
>
> http://forums.java.net/jive/thread.jspa?messageID=474867
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>