Also, if you use Hibernate, you can use:
*Session.createFilter*(city.getAddresses(), "where this.name like
'S%'").list();
On Tue, Apr 28, 2009 at 5:31 AM, Derek Chen-Becker <dchenbec...@gmail.com>wrote:
> OK, for one, the bidirectional mapping adds no cost in terms of DB access
> other than the time it takes you to write it. Collections are lazily loaded,
> so unless your code *retrieves* City.addresses, the database never gets hit.
> JPA is really not designed with the concept of entities having access to the
> EntityManager that loaded them, although there may be some provider-specific
> way to get at it. Unfortunately, you're on your own if you want an entity to
> obtain other entities via queries or some other non-relationship means.
> Generally, if you need that kind of coverage you should do it through logic
> code that can glue things together instead of tying it to your entities.
> After all, I'd argue that if the logic isn't part of what you can express in
> the database then it doesn't belong in the entity classes anyways. When you
> say "bogged down in bidirectional mappings" are you referring simply to the
> overhead of adding the mappings to your entities, or do you think that
> there's some performance issue with bidirectional mappings (AFAIK, there
> aren't any).
>
> Derek
>
>
>
> On Mon, Apr 27, 2009 at 6:01 PM, TSP <tim.pig...@optrak.co.uk> wrote:
>
>>
>> There are two questions here. I don't really want to get bogged down
>> in bidrectional mappings I was rather hoping for suggestions on how my
>> domain objects might simply get at the right Model transparently from
>> both application and junit (in Grails it was done with Spring
>> injection - here perhaps an EMF factory (a factory-factory?)) However,
>> in answer to the bidirectional mapping question here is an example:
>>
>> class City {
>> var name: String;
>> var population: Int;
>> // var addresses: java.util.Set[Address] // BAD because London has
>> approx 3m addresses
>>
>> }
>>
>> class Address {
>> name, street etc
>> var city: City
>> }
>>
>> object Address {
>> def matchAddress( .. unstructured input strings from ERP
>> system ...) = {
>> ,,,
>> Some[Address]
>> else
>> None
>> }
>> }
>>
>>
>> class Organisation {
>> var hq: Address;
>> }
>>
>> So I can easily trace from organisation to it's address and then find
>> out if the organisation is in a big city.
>> But I never need to directly fetch the city and iterate through the
>> addresses.
>>
>> There are many more examples where the many side of things runs into
>> hundreds and thousands (shipments to a daily customer over the last 2
>> years, tracking events on trucks at 1 minute intervals stored for 6
>> months).
>>
>> Again with reference to Evans Domain Driven Design for a large and
>> complex domain model (I expect to end up with well over 50 objects)
>> universal bi-directional mappings are strongly discouraged (see for
>> example discussion on p. 83)
>>
>> Now you might argue that my address matching should be delegated to a
>> service, but the techniques can be quite country specific tying in the
>> postcodes and town names for example or dealing with peculiarities
>> (from my point of view) of US street naming conventions - so I want my
>> address matching tied closely to may data objects (in that case it
>> would be Address subclasses). Also as soon as I do get rid of bi-
>> directional mappings then any direct business logic that requires
>> traversal in the "missing" direction can be readily accomplished by
>> access to the database.
>>
>> On Apr 27, 11:00 pm, Derek Chen-Becker <dchenbec...@gmail.com> wrote:
>> > I may be misunderstanding this, but if you just do bidirectional
>> mappings in
>> > JPA then the DB query is generally efficient and transparent. Could you
>> post
>> > a little snippet showing what you're trying to do?
>> >
>> > Derek
>> >
>> > On Mon, Apr 27, 2009 at 2:44 PM, TSP <tim.pig...@optrak.co.uk> wrote:
>> >
>> > > Viktor,
>> > > It's a valid point, and I would where possible but I've got quite a
>> > > lot of uni-directional references (for example, addressable locations
>> > > in a city) where using a mapping would entail very large fetches that
>> > > are better handled by querying the database. Evans in Domain Driven
>> > > Design is very keen on uni-directional references and who am I to
>> > > argue :-)
>> > > Tim
>> >
>> > > On Apr 27, 9:10 pm, Viktor Klang <viktor.kl...@gmail.com> wrote:
>> > > > Why don't collection mappings work?
>> >
>> > > > Also, from personal experience, mixing persistence-logic in domain
>> > > objects
>> > > > does make you feel somewhat naughty.
>> >
>> > > > On Mon, Apr 27, 2009 at 9:15 PM, Tim P <tim.pig...@optrak.co.uk>
>> wrote:
>> >
>> > > > > Hi
>> > > > > I'm looking for some guidance here and I don't think this is
>> addressed
>> > > > > in the book.
>> >
>> > > > > I've got domain classes that need to go get stuff from the
>> database
>> > > > > "list all ... " type of methods.
>> > > > > So presumably my domain class should have, or be allowed to have
>> > > > > methods that access Model
>> > > > > But my unit tests need to test these methods. So I need a model
>> which
>> > > > > is instantiated within the test environment and so does not need
>> to be
>> > > > > extended with RequestVarEM which presumably would be a bad thing
>> > > > > (though perhaps it's harmless).
>> > > > > Any suggestions on "best practice" to achieve this? (I'm still
>> very
>> > > > > much trying to find my way round natural scala constructs)
>> >
>> > > > > Should it be mentioned in the jpa chapter in the book?
>> >
>> > > > > Tim
>> >
>> > > > --
>> > > > Viktor Klang
>> > > > Senior Systems Analyst
>>
>>
>
> >
>
--
Viktor Klang
Senior Systems Analyst
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
