RE: [Compass-developer] Cyclic dependency
Brought to you by:
kimchy
From: Jeroen R. <Jer...@ve...> - 2005-05-30 12:14:42
|
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> > |