incubator-empire-db-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Döbele <doeb...@esteam.de>
Subject re: Bean handling in 1:n relationships or joins
Date Wed, 07 Dec 2011 22:34:29 GMT
Hi Jens, 

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
> 
> Hi Rainer!
> 
> 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?
> 
> Consider we have an entity A and B
> A (name)
> B (whatever1, whatever2, FK_to_A)
> 
> 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??
> 
> Jens
> 
> 
> Btw: thanks for the quick response.
> 
> 
> Am 07.12.11 18:41, schrieb Rainer Döbele:
> > 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


Mime
View raw message