Re: [Compass-developer] Cyclic dependency

[Shay B. <ki...@ma...>]

Hi Jeroen,

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

   Why am I asking this? Since the main use case that I envisioned  
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  
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  
using Compass) using the profile id from Compass.

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


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

     Mappings:

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

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

         <id name="id" />

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

         ...

     </class>

     <class name="Profile" alias="profile" root="false">
         <id name="id">
           <meta-data store="yes" index="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  
stores and un_tokenized. That way, Compass won't automatically create  
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  
profile can be:

CompassHits hits = session.find("profile-id:7"); // find the account  
which has profile with id 7
Account account = (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,  
related profiles will have to be derived from it. As well, a search  
for a specific data in a profile, will return it's corresponding  
Account, and all the Account profiles. If these are your search  
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  
> configuring it, this has become the same-old boring effort. So,  
> some feature, for example an ant-task that could help generate the  
> initial configuration of the model would be great.
>
> One of the biggest benefits of Compass is definitely its  
> simplicity. It took me only a small amount of time to understand  
> the concepts and to start using it. The samples are good and  
> useful. I was missing some explanation about how inheritance in the  
> model is treated, but after giving it some thought there is nothing  
> to it. However I think this may be a common question, so you should  
> point it out somewhere in the documentation or examples.
>
> At the moment we're using just Compass::Core, proving the concepts.  
> If it is useful enough we will integrate it in our project using  
> Compass::Spring. If we go ahead with this, we will of course have  
> to go through the phase of loading our initial data into the search  
> engine, so the GPS portion will probably be very useful here too,  
> especially with the capabilities of listening to data changes in  
> the underlying datastorages so the searchindexes can be updated as  
> 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  
> cyclic dependencies.
>
> We have a Services layer that has a number of configurable DAO  
> 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  
> cyclic dependency when configuring it in Compass. I am sure you  
> have seen it yourself, it causes the VM to blow up with an  
> OutOfMemory error (its looping in the MappingBindingSecondPass-class).
>
> Well, I could get around this issue by not configuring one of the  
> associations (for example "has account").
> When loading Account from the findAccount() method this is not a  
> problem. The relation from Profile to Account can be populated  
> after the search to fully populate the model.
> When loading the Profile from the findProfile() method we have a  
> problem. The relation from Profile to Account is not known, since  
> 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  
> next version you will be able to automatically index a database  
> (very simple if you are using hibernate or ojb, or just simple  
> directly pointing to the database). I added some features to  
> Compass::Core as well, but cyclic dependencies was not high on my  
> list (but you gave it a nudge and it moved up).
>
>    I will try to implement it in the next release (though cascading  
> jumps immediately to mind, and that will be more complicated  
> because of automatic dirty checking).
>
>    If you wish to find a workaround, I will need to know more about  
> the system you are working on. Especially if you are using Compass  
> as your data store as well (and not database, xml). Since if you  
> are not using Compass as your sole data store, you can use it and  
> your mappings from the data store to your domain model, to traverse  
> the data. What I mean is that once you found something with  
> compass, show it to the user, and than once it is selected, load  
> the actual data from the persistent data store.
>
>   The next release is planned to be in about 4 to 5 weeks (maybe  
> sooner), since we are changing many things in terms of  
> documentation, the site, and Compass::Gps.
>
>   By the way, what do you think about compass, are there any other  
> enhancements that you feel are missing and would like to see in the  
> 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,  
> are there any workarounds that I could use?
>
>     Or, can you tell me when support is planned?
>
>     Thanks,
>     Jeroen
>
>
>
>
>
>
> <winmail.dat>
>