Return-Path: 
 <empire-db-user-return-378-apmail-incubator-empire-db-user-archive=incubator.apache.org@incubator.apache.org>
X-Original-To: apmail-incubator-empire-db-user-archive@minotaur.apache.org
Delivered-To: apmail-incubator-empire-db-user-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 3EBAF76E4
	for <apmail-incubator-empire-db-user-archive@minotaur.apache.org>;
 Wed,  7 Dec 2011 22:34:59 +0000 (UTC)
Received: (qmail 87659 invoked by uid 500); 7 Dec 2011 22:34:59 -0000
Delivered-To: apmail-incubator-empire-db-user-archive@incubator.apache.org
Received: (qmail 87643 invoked by uid 500); 7 Dec 2011 22:34:59 -0000
Mailing-List: contact empire-db-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:empire-db-user-help@incubator.apache.org>
List-Unsubscribe: <mailto:empire-db-user-unsubscribe@incubator.apache.org>
List-Post: <mailto:empire-db-user@incubator.apache.org>
List-Id: <empire-db-user.incubator.apache.org>
Reply-To: empire-db-user@incubator.apache.org
Delivered-To: mailing list empire-db-user@incubator.apache.org
Received: (qmail 87635 invoked by uid 99); 7 Dec 2011 22:34:58 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Dec 2011 22:34:58 +0000
X-ASF-Spam-Status: No, hits=1.6 required=5.0
	tests=RCVD_IN_BRBL_LASTEXT,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: local policy)
Received: from [88.79.172.157] (HELO mail.esteam.de) (88.79.172.157)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Dec 2011 22:34:50 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
Subject: re: Bean handling in 1:n relationships or joins
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 7 Dec 2011 23:34:29 +0100
Message-ID: <B297D4737108A0459B66C3A85BB7F90133B7B4@kn.esteam.de>
In-Reply-To: <4EDFD41C.3040202@j-b-s.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: re: Bean handling in 1:n relationships or joins
thread-index: Acy1I3CMFtpqfV5/SJWF7rVfZ1dVpQACxfXA
References: <4EDE4BCD.3010507@j-b-s.de>
 <B297D4737108A0459B66C3A85BB7F90133B7B0@kn.esteam.de>
 <4EDFD41C.3040202@j-b-s.de>
From: =?iso-8859-1?Q?Rainer_D=F6bele?= <doebele@esteam.de>
To: <empire-db-user@incubator.apache.org>
X-Virus-Checked: Checked by ClamAV on apache.org

Hi Jens,=20

well, yes and no.

OO mappers usually work with bean that represent full entities.

In most queries I use (selecting items for display in a list e.g.) I =
don't need a full entitiy.
In fact my tables usually have many columns and there is no point =
selecting columns I don't need.
Instead I need a combination of fields from different tables and views.

So in your case with your query:

select A.name, B.whatever1, B.whatever2

I would expect to receive a List<QAB> where QAB is a class created =
specifically for this query (I use nested classes a lot). E.g.
class QAB {
 	String name; // from table A
	Object whatever1;	// from table B
	Ojbect whatever2; // from table B
	...
	// + Getters and Setters for all properties
}

Only in the detail view I normally need a full entitiy. But then I'd =
rather use a DBRecord instead of a bean.

But there is always room to build something on top.
And if you feel that you have created something that could be =
interesting for a greater audience, we would be grateful to receive and =
check your code and possibly we would then add it to our code base. =
Apache is all about contribution and getting new ideas in from other =
people.

Regards
Rainer


> from: Jens Breitenstein [mailto:mailinglist@j-b-s.de]
> to: empire-db-user@incubator.apache.org
> re: Re: Bean handling in 1:n relationships or joins
>=20
> Hi Rainer!
>=20
> I know it's not a full blown oo mapper and that was exactly the reason
> to give empire a chance after some painful hibernate experiences in
> past
> projects...
> What about extending the getBeansList method to pass in a list of
> classes to support an OO mapping for lets say one hierarchy?
>=20
> Consider we have an entity A and B
> A (name)
> B (whatever1, whatever2, FK_to_A)
>=20
> In case we select A.name, B.whatever1, B.whatever2 by a join it's
> really
> comfortable to operate on a list<object[A, B]> having all parameters
> properly filled instead of an FK which requires an additional select
> per
> row?
> I have not digged into the sources yet but I believe its not far from
> what currently exists, or am I wrong? Maybe we can add it to a
> XMas-Wishlist??
>=20
> Jens
>=20
>=20
> Btw: thanks for the quick response.
>=20
>=20
> Am 07.12.11 18:41, schrieb Rainer D=F6bele:
> > Hi Jens,
> >
> > remember that Empire-db is not an OR-Mapper and it does nothing
> automatically.
> > In exchange it gives you more control over what, when and how
> database operations are performed.
> >
> > Even though beans can be used as data containers, they will not
> provide the same level of functinality than a DBRecord does.
> >
> > Again I recommend to take a look at our examples empire-db-example-
> basic and empire-db-example-advanced.
> > Regards
> >
> > Rainer
> >
> >
> >> from: Jens Breitenstein [mailto:mailinglist@j-b-s.de]
> >> to: empire-db-user@incubator.apache.org
> >> re: Bean handling in 1:n relationships or joins
> >>
> >> Hi all!
> >>
> >> I have to admit I am pretty new to empire-db but feel quite
> confortable
> >> with it...
> >> Finally I got the Bean mapping working for single tables and I now
> get
> >> stuck in how to handle joins correctly...
> >>
> >> Assume a simple relationship between a document and a user (where
> the
> >> users-pk is part of the documents as fk to indicate a relation
> >> "document
> >> is owned by user").
> >> Using the getBeanList method it seems only possible to convert a
> "root"
> >> element (in my case the document) but not any referenced element
> >> automatically?
> >> If I am wrong can someone explain me how I can retrieve a =
"document"
> >> having a fully instantiated "user" element instead of just an FK?
> >> Or do I have to read the user record manually and the bean handling
> >> does
> >> not support joined objects at all?
> >>
> >> thanks in advance
> >>
> >> Jens