Menu
▾
▴
Re: [Lmappletserver-developers] Problem with saved searches when adding a new metadata after the search is saved
|
From: Peter S. <co...@pe...> - 2007-11-07 12:54:33
|
Super - looks good! Peter On Nov 6, 2007 11:32 PM, Roberto MIlev <rob...@gm...> wrote: > 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 > > > > > |
