Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #19511 > unrolled thread

How to store and represent 1 objects relationship to other objects

Back to article view | Back to comp.lang.java.programmer

Contents

  How to store and represent 1 objects relationship to other objects pat.trainor@gmail.com - 2012-10-26 11:40 -0700
    Re: How to store and represent 1 objects relationship to other objects Lew <lewbloch@gmail.com> - 2012-10-26 12:23 -0700
    Re: How to store and represent 1 objects relationship to other objects Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-10-26 22:59 +0200
      Re: How to store and represent 1 objects relationship to other objects Lew <lewbloch@gmail.com> - 2012-10-26 14:51 -0700
        Re: How to store and represent 1 objects relationship to other objects Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-10-27 00:48 +0200
          Re: How to store and represent 1 objects relationship to other objects Lew <lewbloch@gmail.com> - 2012-10-26 16:07 -0700
        Re: How to store and represent 1 objects relationship to other objects Gene Wirchenko <genew@ocis.net> - 2012-10-28 20:47 -0700
          Re: How to store and represent 1 objects relationship to other objects David Lamb <dalamb@cs.queensu.ca> - 2012-10-29 10:12 -0400

#19511 — How to store and represent 1 objects relationship to other objects

In other words and this maybe a database question, 1 of many thousands of objects is related to any number of other objects. The problem is how to represent or index those relationships each 1 being perhaps either a parent, a child, or a peer of 1 or more thousands of objects. 

I fully realize that this might in fact be a database question, so forgive me if this ends up being so. Because I use Hibernate and JPA I simply consider this a Java question with persistent simply being the implementation of how to Java objects are designed.

TIA for your thoughts.

:)

[toc] | [next] | [standalone]

#19515

On Friday, October 26, 2012 11:40:51 AM UTC-7, pat.t...@gmail.com wrote:
> In other words and this maybe a database question, 1 of many thousands of objects is related to any 
> number of other objects. The problem is how to represent or index those relationships each 1 being 
> perhaps either a parent, a child, or a peer of 1 or more thousands of objects. 
> 
> I fully realize that this might in fact be a database question, so forgive me if this ends up being so.
> Because I use Hibernate and JPA I simply consider this a Java question with persistent simply being
> the implementation of how to Java objects are designed.

If you use JPA, presumably you have access to JPA docs, which explain how this is handled.
http://docs.oracle.com/javaee/6/tutorial/doc/bnbpy.html
et seq.

Take note of the annotations '@OneToOne', '@OneToMany', '@ManyToMany' and '@ManyToOne'.
http://docs.oracle.com/javaee/6/tutorial/doc/bnbqa.html#bnbqh

A quick search for "Java JPA" turned this up:
http://www.oracle.com/technetwork/articles/javaee/figure6-137029.html

In fact, I bet you could find all sorts of answers to your questions with a bit of a search:
http://lmgtfy.com/?q=Java+JPA+relationships

What do you mean by "peer", incidentally?

How would you model relationships between entities in your code if there were no database?

Really, this is the question. JPA is for persistence of an object model, not for coding a 
relational model.

When you say, "Hibernate and JPA", I will presume you mean "Hibernate as JPA". There is no 
better way to use Hibernate.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#19518

On 26/10/2012 20:40, pat.trainor@gmail.com allegedly wrote:
> In other words and this maybe a database question, 1 of many
> thousands of objects is related to any number of other objects. The
> problem is how to represent or index those relationships each 1 being
> perhaps either a parent, a child, or a peer of 1 or more thousands of
> objects.
> 
> I fully realize that this might in fact be a database question, so
> forgive me if this ends up being so. Because I use Hibernate and JPA
> I simply consider this a Java question with persistent simply being
> the implementation of how to Java objects are designed.
> 
> TIA for your thoughts.
> 
> :)

I have trouble understanding your question, especially why you pose it
in such an abstract manner.

It's your data you're talking about, right? Well, then you'd better know
darn well how they're related. Once you have established what those
relationships are, you map them. There ain't many candidates. You've got
many-to-one, one-to-many, unidirectional one-to-one and bidirectional
one-to-one relationships. That's about it.

Your starting point must be to analyse what you're modelling, methinks.

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#19522

Daniele Futtorovic wrote:
> pat.trainor@ allegedly wrote:
>> In other words and this maybe a database question, 1 of many
>> thousands of objects is related to any number of other objects. The
>> problem is how to represent or index those relationships each 1 being
>> perhaps either a parent, a child, or a peer of 1 or more thousands of
>> objects.
> 
> I have trouble understanding your question, especially why you pose it
> in such an abstract manner.
> 
> It's your data you're talking about, right? Well, then you'd better know

If so, then that's bad. They should be talking about their object model.

> darn well how they're related. Once you have established what those
> relationships are, you map them. There ain't many candidates. You've got
> many-to-one, one-to-many, unidirectional one-to-one and bidirectional
> one-to-one relationships. That's about it.
> 
> Your starting point must be to analyse what you're modelling, methinks.

Yes, from an object-modeling standpoint.

A common mistake with JPA is to use it as a glorified JDBC, with a data-centric
approach. Its purpose is to provide an object-centric approach that maps to a 
data store, not to replace relational modeling or even represent it.

So first question to analyze while modeling: what entities relate to what entities?
How do you model that relationship?

For example, if a retail order system models than an "Order" has multiple "Line Items" 
for which reproducible order matters, you likely would have an object model that includes

  public class Order
  {
    List<LineItem> lineItems;
  ...
  }

If you further wish to guarantee that no 'LineItem' appears more than once, you'd likely use a 'Set'
instead of a 'List'. Unfortunately the JPA spec doesn't seem to allow 'SortedSet', but it seems that 
the '@OrderBy' annotation hacks around that limitation.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#19523

On 26/10/2012 23:51, Lew allegedly wrote:
> Daniele Futtorovic wrote:
>> pat.trainor@ allegedly wrote:
>>> In other words and this maybe a database question, 1 of many
>>> thousands of objects is related to any number of other objects. The
>>> problem is how to represent or index those relationships each 1 being
>>> perhaps either a parent, a child, or a peer of 1 or more thousands of
>>> objects.
>>
>> I have trouble understanding your question, especially why you pose it
>> in such an abstract manner.
>>
>> It's your data you're talking about, right? Well, then you'd better know
> 
> If so, then that's bad. They should be talking about their object model.

My emphasis was on "your" -- in the sense of: something the OP ought to
be closely acquainted with. His use of the word "objects" could be
interpreted to mean that the model is already in place. But either way,
you Lew make a very valid point.

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#19524

Daniele Futtorovic wrote:
> Lew allegedly wrote:
>> Daniele Futtorovic wrote:
>>> pat.trainor@ allegedly wrote:
>>>> In other words and this maybe a database question, 1 of many
>>>> thousands of objects is related to any number of other objects. The
>>>> problem is how to represent or index those relationships each 1 being
>>>> perhaps either a parent, a child, or a peer of 1 or more thousands of
>>>> objects.
> 
>>> I have trouble understanding your question, especially why you pose it
>>> in such an abstract manner.
>>>
>>> It's your data you're talking about, right? Well, then you'd better know
>> 
>> If so, then that's bad. They should be talking about their object model.
> 
> My emphasis was on "your" -- in the sense of: something the OP ought to
> be closely acquainted with. His use of the word "objects" could be
> interpreted to mean that the model is already in place. But either way,
> you Lew make a very valid point.

As do you, Daniele. As did Arved in another communication.

Despite what I said, I recognize that JPA can, and sometimes should be used as 
a way to adopt a database model into an object model, rather than simply persist 
the object model. JPA is not intended for overly rococo data models, such as the 
kind where every DBA trick in the book is pulled, but within its intended sphere it is 
very useful to impose an object model atop a data model.

But that doesn't mean one should program the application the same as if they were 
using JDBC. In such a situation, why not use JDBC? The idea is to graft an *object* model 
onto the data, or use the datastore to persist the *object* model, not to write Java code for 
a relational model. That's the reason for having a mapping at all between object and relational 
models, that is, an object-relational mapping (ORM).

JPA is not for writing relational code. That's what JDBC is for.

There's a lot more to JPA than that, of course. In my own experience I've found a very 
effective idiom for JPA, but I'm having trouble articulating it. I've even written code comparing 
a "classic" monolithic Hibernate approach (a giant Session for everything) vs. a "modern" JPA 
approach - tiny data-access helpers each with their own EntityManager, one per service. (Also
used Hibernate for that one.) The tiny-helper approach was much easier to work with and 
understand and optimize, IMO. I've been on a few projects where the monolithic ORM session 
caused huge problems. 

It's the same sort of thing that has Java coders write local object references inside a loop instead 
of longer-lived ones declared outside the loop. The short-lived objects release their resources 
quicker (e.g., don't move to the tenured generation) and are easier to reason about.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#19551

On Fri, 26 Oct 2012 14:51:49 -0700 (PDT), Lew <lewbloch@gmail.com>
wrote:

[snip]

>If you further wish to guarantee that no 'LineItem' appears more than once, you'd likely use a 'Set'
>instead of a 'List'. Unfortunately the JPA spec doesn't seem to allow 'SortedSet', but it seems that 
>the '@OrderBy' annotation hacks around that limitation.

     Sets (in the mathematical sense) do not have order.  If you want
to have an order, use a list.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#19554

On 28/10/2012 11:47 PM, Gene Wirchenko wrote:
> On Fri, 26 Oct 2012 14:51:49 -0700 (PDT), Lew <lewbloch@gmail.com>
> wrote:
>
> [snip]
>
>> If you further wish to guarantee that no 'LineItem' appears more than once, you'd likely use a 'Set'
>> instead of a 'List'. Unfortunately the JPA spec doesn't seem to allow 'SortedSet', but it seems that
>> the '@OrderBy' annotation hacks around that limitation.
>
>       Sets (in the mathematical sense) do not have order.  If you want
> to have an order, use a list.

Mathematically he's looking for an injective sequence -- one where there 
is an order but where no element occurs more than once. It's neither a 
simple list nor a simple set, so I'm not surprised that there's some 
sort of of "@OrderedSet" annotation grafted onto a conventional data 
structure.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web