compass-developer — Compass Developer Mailing List

[Compass-developer] Complex querying

[Brian M. <bri...@gm...>]

Hi guys,

first off, I think Compass is very cool as an idea and I've started to play
around with it. What I really want to use compass for however is more
standard querying. For example, I want to query across tables (for example
using joins). Also, I want to be able to order the search results etc.

1) Is this possible,

2) Can you guys possibly modify the example petclinic application to show
off those types of queries.

thanks very much,

Brian

[Compass-developer] mapping problem

[matthew b. <bil...@ho...>]

Hi!
I am having problems with a parent-child mapping that should be  
simple but for the life of me I just cannot figure out what I am  
doing wrong!

The mapping below works fine. I can query 'male' and all male people  
and staff are returned - fantastic!

<compass-core-mapping>
     <class name="a.b.x.Person" alias="person">
         <id name="id"/>
         <property name="gender">
             <meta-data>gender</meta-data>
         </property>
     </class>
     <class name="a.b.x.Staff" alias="staff">
         <id name="id"/>
         <property name="number">
             <meta-data>number</meta-data>
         </property>
         <component name="identity" ref-alias="person"/>
     </class>
</compass-core-mapping>

When I advance a little using the mapping below I get stuck! I now  
query 'male' and get no hits returned. A query using initials that  
definitely exist in my database also returns no hits (I was hoping to  
get some people and staff returned).

<compass-core-mapping>
     <class name="a.b.x.Person" alias="person">
         <id name="id"/>
         <property name="gender">
             <meta-data>gender</meta-data>
         </property>
         <component name="names" ref-alias="personName"/>
     </class>
     <class name="a.b.y.PersonName" alias="personName" root="false">
         <property name="initials">
             <meta-data>initials</meta-data>
         </property>
     </class>
     <class name="a.b.x.Staff" alias="staff">
         <id name="id"/>
         <property name="number">
             <meta-data>number</meta-data>
         </property>
         <component name="identity" ref-alias="person"/>
     </class>
</compass-core-mapping>

I have probably made a mistake somewhere (or missed the point). Any  
help or advice would be appreciated.

Thanks - Matt

Re: [Compass-developer] Invalid Error Message

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

    Great, Thanks! Save operation actually consists of delete and than 
create, thats why you got the delete error message, I will change it. 
Even the most minor things that bug you, I would really appreciate you 
reporting it.

    Shay

Todd McGregor wrote:

>I got the following error message when trying to call
>the save method with transaction isolation set to
>batch_insert:
>
>org.compass.core.engine.SearchEngineException: Delete
>operation not supported for batch update transaction
>
>It should say "Save operation not supported. . ."
>
>Not a big deal, but I thought I would pass it along.
>
>
>		
>____________________________________________________
>Start your day with Yahoo! - make it your home page 
>http://www.yahoo.com/r/hs 
> 
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>_______________________________________________
>Compass-developer mailing list
>Com...@li...
>https://lists.sourceforge.net/lists/listinfo/compass-developer
>  
>

[Compass-developer] Invalid Error Message

[Todd M. <tod...@ya...>]

I got the following error message when trying to call
the save method with transaction isolation set to
batch_insert:

org.compass.core.engine.SearchEngineException: Delete
operation not supported for batch update transaction

It should say "Save operation not supported. . ."

Not a big deal, but I thought I would pass it along.


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

[Compass-developer] Compass 0.5.1 Released

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

Hi,

    Compass 0.5.1 released. It mainly fixes a Hibernate lazy loading bug 
as noted by Chrisitan Gruber.

Shay

[Compass-developer] Compass 0.5 Released

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

We are please to announce the 0.5 major feature release of Compass 
Object/Search Engine Mapping (OSEM) framework. This release makes 
integrating search capability with existing development frameworks (like 
Hibernate and Spring) even simpler. Compass uses declarative mapping 
technology, which means you: Write less code, find data faster.
 
Changes includes: GPS (extendable datasource integration) device 
technology for Hibernate 2/3, JDO, OJB and JDBC. Improved integration 
with Spring framework for configuration, MVC and ORM support.
 
Compass core changes includes, improved performance of reader/searcher 
and Optimizers, support for binary data indexing, cyclic references and 
extending the mapping capabilities. Plus many more features. It will 
change the way you search application data.

[Compass-developer] Upgrade to 0.5

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

Hi,

   I am upgrading the site as part of the next release. It might be 
un-available for the next hour.

Shay

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

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

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

RE: [Compass-developer] Cyclic dependency

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

Hi Shay,
=20
Thanks for your quick and elaborate reply.=20
=20
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.=20
=20
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.
=20
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.
=20
Some explanation of our system, to give you some clues on the cyclic =
dependencies.=20
=20
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.=20
=20
A simplified model could be described as follows:=20
=20
* Account
* has Profiles
=20
* Profile
* has account
=20
Some simple methods in our DAO layer may be:=20
=20
public Account findAccount() {
   // Returns Account and its profiles
}
public Profile findProfile() {
    // Returns Profile and its associated Account
}
=20
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).=20
=20
Well, I could get around this issue by not configuring one of the =
associations (for example "has account").=20
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.=20
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...
=20
Hope you can help!
=20
Good luck with your work on Compass!
=20
Jeroen
=20
=20
=20
=20
=20
=20
=20
=20

________________________________

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,
	=20
	Knowing that there is no support yet for cyclic dependencies, are there =
any workarounds that I could use?
	=20
	Or, can you tell me when support is planned?=20
	=20
	Thanks,
	Jeroen
	=20
	=20
	=20

Re: [Compass-developer] Cyclic dependency

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

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

[Compass-developer] Cyclic dependency

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

Hello there,
=20
Knowing that there is no support yet for cyclic dependencies, are there =
any workarounds that I could use?
=20
Or, can you tell me when support is planned?=20
=20
Thanks,
Jeroen
=20
=20
=20

[Compass-developer] Compass 0.4 Released

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

[Compass-developer] Welcome

[<kim...@ma...>]

[Compass-developer] Welcome to Compass

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

[Compass-developer] Welcome to Compass Developer Mailing List

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

[Compass-developer] Welcome to Compass Developer list

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