Re: [Compass-developer] Cyclic dependency

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

Forgot one more thing, regarding your comments.

    Regarding an ant task to generate the mappings files, I was  
thinking about adding Annotations support (using a framework that  
supports 1.4 as well, like commons-attributes), and maybe xdoclet.  
Though I will probably get around to implement it towards version  
1.0, since I would much rather enhance Compass features at runtime.  
Of course, if the community will press, it might get bumped and will  
be implemented sooner.

    I will add more documentation about the inheritance part, thanks  
for the heads up. A new feature that will be available in the next  
version is the ability to extend several other mappings (yes, the  
evil multiple inheritance :-), which is not at all evil in our case),  
as well defining contracts, which are a mapping definitions with no  
class defined in them, and they can also be extended (a cross bread  
between interfaces and abstract classes in Java terms).

    Performance have been greatly improved in the next version as  
well, so if you think that compass is fast now, wait till the next  
release.

    I am happy that you found compass easy to use and hopefully  
enjoyable, I am doing my best to make it so.

Cheers
   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>
>