Menu
▾
▴
Re: [Lmappletserver-developers] Problem with saved searches when adding a new metadata after the search is saved
|
From: Roberto M. <rob...@gm...> - 2007-11-06 22:32:09
|
Hi Peter, Thanks for the tip. I have already fixed, tested and committed the changes regarding this issue. Regards, Roberto Peter Salomonsen wrote: > Hi Roberto, > > We should make the default behavior so that when leaving the > lmappletserver_metaloginterceptors.properties file empty, then the > DefaultInterceptor should just return > > return ctx.proceed(); > > I or you can fix this - tell me what's best. We should also rename the > properties file so that it is called > lmappletserver_addons_ejbinterceptors (more generic). I also see that > the interceptor code is using HashMap while it rather could be using > HashSet (minor details :)... > > regards, > > Peter > > On 10/30/07, *Roberto MIlev* <rob...@gm... > <mailto:rob...@gm...>> wrote: > > Hi Peter, > > First an update regarding the interceptors and my lmappletserver > setup. > Leaving the lmappletserver_metaloginterceptors.properties file empty > defaults to the DefaultInterceptor being called. However this > caused all > the queries to return null. I read up on writing around methods, and I > cant seem to find the InvocationContext.proceed() signal being > called by > the default interceptor. I got everything working once I explicitly > turned the interceptor off. > > Regards, > Roberto > > Roberto Milev wrote: > > Hi Peter, > > > > I changed and commiter orm.xml. I will be looking at the interceptor > > stuff next. I will keep you posted. > > > > Regards, > > Roberto > > > > On 10/23/07, * Peter Salomonsen* <co...@pe... > <mailto:co...@pe...> > > <mailto: co...@pe... > <mailto:co...@pe...>>> wrote: > > > > Hi Robert, > > > > I've attached a metaloginterceptors property file example. > This is > > a feature me and Jon has been working on, and the purpose is > to be > > able to intercept calls within the lmappletserver-addons ejb3 > > session beans using default EJB3 interceptors. > > > > I wasn't aware that it was a requirement to have this file, so > > this is a bug, the intention is that this file is not required, > > but an option if you need to create an interceptor for some > > reason. And it really shouldn't be called > metaloginterceptor, as > > it is really intercepting everything - this naming is related to > > our specific use case - we should change this however to a more > > generic name (maybe just interceptor). > > > > To tell you about our use case - we use interceptors to > perform a > > parallell query on searchLogEntries (historic searches). We > have a > > MetaDataLogEntry table with more than a billion of records, and > > the standard query produced by searchLogEntries is not able to > > handle this. The strategy is then to intercept the call, and > > duplicate it to run in multiple processes / servers on smaller > > dataset partitions, and collect the resultsets when sufficient > > amount of threads has returned. Then we also gain our desired > > speed (which is instant results). > > > > About table names - since the case problem is TopLink specific, > > could we rather solve this using an orm.xml for the unit tests? > > Instead of using the Table annotation? > > > > regards, > > > > Peter > > > > > > On 10/21/07, *Roberto MIlev* < rob...@gm... > <mailto:rob...@gm...> > > <mailto:rob...@gm... > <mailto:rob...@gm...>>> wrote: > > > > Hi Peter, > > > > You will find the changes you requested committed to SVN. A > > few notes: > > > > - I was only abe to test the shownColumns changes with dummy > > hardcoded > > data, beacuse I am getting errors due to missing resource - > > lmappletserver_metaloginterceptors. I am not able to > find this > > resource > > in the project. Perhaps you can shed some light on this? > > - In the mean time I also resolved the issue with the > junt tests > > failing. The thing was that the Toplink JPA always > creates the > > tables > > based on the name of the Entity in uppercase. This was not > > visible until > > i install everything on Linux. the solution is to always > > specify the > > name attribute in the @Table annotation. > > > > Regards, > > Roberto > > > > Peter Salomonsen wrote: > > > Hi, > > > > > > I was just going to update my metadata table by adding > a new > > metadata > > > (new column). I found that the searchdto has a showcolumns > > boolean > > > array, and this causes the requirement that the metadata > > cannot change > > > order or change in size. What happened in my case was that > > > listmetadata returned more columns than the showcolumns > > array, and > > > this caused an ArrayIndexOutOfBounds exception in > > > MetaDataSearchExecutor.java on the showcolumns array. > > > > > > I think this has to be solved differently. The > showcolumns array > > > should rather be a list of metadata_ids rather than > booleans > > - so that > > > it is not dependent on me not changing the metadata > order or > > number of > > > metadatas. > > > > > > Can you fix this? > > > > > > regards, > > > > > > Peter > > > > > > > > > > > > > > -- > > Regards, > > Roberto Milev > > |
