RE: [Compass-developer] Cyclic dependency

[Jeroen R. <Jer...@ve...>]

Shay,
=20
When the finder methods are used, a populated domain model may be =
returned, and not just a single object. Normally only the =
children/siblings of a certain object need to be populated, but in case =
of the Profile the association of the Account must be set as well. This =
may not be ideal, but in our situation it is a necessity.
=20
I was thinking of a solution over the weekend, and it turns out you =
describe the same ideas from the Compass perspective right here, so this =
is great help... thanks a lot!
=20
Jeroen

________________________________

From: Shay Banon [mailto:ki...@ma...]
Sent: Fri 5/27/2005 3:49 PM
To: Jeroen Remmerswaal; com...@li...
Subject: Re: [Compass-developer] Cyclic dependency



Hi Jeroen,

     I have a few more questions regarding the problem. I noticed=20
that the find* methods only return a single object (Account or=20
Profile), and that they will work against Compass. My question is: is=20
Compass the only data store in the application, or are you using a=20
database as well (with hibernate for the ORM).

   Why am I asking this? Since the main use case that I envisioned=20
people using Compass is (using your system domain model):

1. Index the Profile and Account (with name, address, ...).
2. The user has a search box where he can enter his query.
3. The system lists the results (Accounts and Profiles, just=20
Accounts, ...).
4. The user clicks on the relevant hit (lets say a Profile).
5. The system loads the profile from the database store (if it is=20
using Compass) using the profile id from Compass.

    This use case, of course, is only relevant if compass is not your=20
prime/only data store.


    If you still need to have the functionality, a workaround might=20
be to have Account as your root mapping, and Profile as a component=20
mapping. This means that all the profile meta data will be=20
incorporated within the account. Finding an account is still simple=20
(the same way it was before). Finding a profile can be something like:

     Mappings:

<compass-core-mapping package=3D"eg">

     <class name=3D"Account" alias=3D"account">

         <id name=3D"id" />

         <component name=3D"profiles" ref-alias=3D"profile" />

         ...

     </class>

     <class name=3D"Profile" alias=3D"profile" root=3D"false">
         <id name=3D"id">
           <meta-data store=3D"yes" index=3D"un_tokenized" >profile-id</
meta-data>
         </id>

         ....

     </class>

</compass-core-mapping>

Note that we specify the meta-data for the profile id, and that it is=20
stores and un_tokenized. That way, Compass won't automatically create=20
an id for it, so we can then use it in our searches.

Assuming that the profiles have distinct ids, the code to load a=20
profile can be:

CompassHits hits =3D session.find("profile-id:7"); // find the account=20
which has profile with id 7
Account account =3D (Account) hits.get(0); // there should be only one =
hit
// iterate over the profiles and get the profile with id 7

Note however, that now a general query will only return Accounts,=20
related profiles will have to be derived from it. As well, a search=20
for a specific data in a profile, will return it's corresponding=20
Account, and all the Account profiles. If these are your search=20
requirements, than we are ok.

Hope it helped

Shay


On 27 May 2005, at 13:50, Jeroen Remmerswaal wrote:

> Hi Shay,
>
> Thanks for your quick and elaborate reply.
>
> Since Compass brings the complexity of the problem down to just=20
> configuring it, this has become the same-old boring effort. So,=20
> some feature, for example an ant-task that could help generate the=20
> initial configuration of the model would be great.
>
> One of the biggest benefits of Compass is definitely its=20
> simplicity. It took me only a small amount of time to understand=20
> the concepts and to start using it. The samples are good and=20
> useful. I was missing some explanation about how inheritance in the=20
> model is treated, but after giving it some thought there is nothing=20
> to it. However I think this may be a common question, so you should=20
> point it out somewhere in the documentation or examples.
>
> At the moment we're using just Compass::Core, proving the concepts.=20
> If it is useful enough we will integrate it in our project using=20
> Compass::Spring. If we go ahead with this, we will of course have=20
> to go through the phase of loading our initial data into the search=20
> engine, so the GPS portion will probably be very useful here too,=20
> especially with the capabilities of listening to data changes in=20
> the underlying datastorages so the searchindexes can be updated as=20
> a result. All in all, it would just be a perfect fit in our system.
>
> Some explanation of our system, to give you some clues on the=20
> cyclic dependencies.
>
> We have a Services layer that has a number of configurable DAO=20
> layers that point to various downstream systems. One of these DAO-
> layers will make use of Compass.
>
> A simplified model could be described as follows:
>
> * Account
> * has Profiles
>
> * Profile
> * has account
>
> Some simple methods in our DAO layer may be:
>
> public Account findAccount() {
>    // Returns Account and its profiles
> }
> public Profile findProfile() {
>     // Returns Profile and its associated Account
> }
>
> The above model shows a simple one-to-many, but this causes a=20
> cyclic dependency when configuring it in Compass. I am sure you=20
> have seen it yourself, it causes the VM to blow up with an=20
> OutOfMemory error (its looping in the MappingBindingSecondPass-class).
>
> Well, I could get around this issue by not configuring one of the=20
> associations (for example "has account").
> When loading Account from the findAccount() method this is not a=20
> problem. The relation from Profile to Account can be populated=20
> after the search to fully populate the model.
> When loading the Profile from the findProfile() method we have a=20
> problem. The relation from Profile to Account is not known, since=20
> we did not specify it...
>
> Hope you can help!
>
> Good luck with your work on Compass!
>
> Jeroen
>
>
>
>
>
>
>
>
>
> ________________________________
>
> From: Shay Banon [mailto:ki...@ma...]
> Sent: Fri 5/27/2005 1:18 PM
> To: Jeroen Remmerswaal; com...@li...
> Subject: Re: [Compass-developer] Cyclic dependency
>
>
> Hi,
>
>    I am currently working on Compass::Gps, which means that in the=20
> next version you will be able to automatically index a database=20
> (very simple if you are using hibernate or ojb, or just simple=20
> directly pointing to the database). I added some features to=20
> Compass::Core as well, but cyclic dependencies was not high on my=20
> list (but you gave it a nudge and it moved up).
>
>    I will try to implement it in the next release (though cascading=20
> jumps immediately to mind, and that will be more complicated=20
> because of automatic dirty checking).
>
>    If you wish to find a workaround, I will need to know more about=20
> the system you are working on. Especially if you are using Compass=20
> as your data store as well (and not database, xml). Since if you=20
> are not using Compass as your sole data store, you can use it and=20
> your mappings from the data store to your domain model, to traverse=20
> the data. What I mean is that once you found something with=20
> compass, show it to the user, and than once it is selected, load=20
> the actual data from the persistent data store.
>
>   The next release is planned to be in about 4 to 5 weeks (maybe=20
> sooner), since we are changing many things in terms of=20
> documentation, the site, and Compass::Gps.
>
>   By the way, what do you think about compass, are there any other=20
> enhancements that you feel are missing and would like to see in the=20
> next version? What are modules are using with compass?
>
>   Cheers
> Shay
>
>
> On 27 May 2005, at 12:36, Jeroen Remmerswaal wrote:
>
>
>     Hello there,
>
>     Knowing that there is no support yet for cyclic dependencies,=20
> are there any workarounds that I could use?
>
>     Or, can you tell me when support is planned?
>
>     Thanks,
>     Jeroen
>
>
>
>
>
>
> <winmail.dat>
>