Hi, Thanks for this input Martin, it makes the hard part of the problem clearer in my mind. > I'm reading this... Cool idea, definitely. But it gets into deep > water very quickly, depending on how fancy you want to get. > > I don't think there's anything in the current model that limits this per > se - this kind of functionality would be built underneath the current > FeatureCollection and DataSource interfaces. > > The easiest step in this direction is to add the ability to join to a > layer that is already in memory. It sounds like mentaer has made some > steps in this direction, but in a "materialized" way. The next step is > to make the join to the memory layer dynamic, so it is executed on the > fly, without requiring new storage to be allocated for the join layer. I have a plugin which computes an attribute dynamically (actually it computes from another attribute of the same table, but loading from another table would probably be possible with good indexes). Unfortunately, I've never made it completely robust. As far as I remember, I had to create a DynamicFeature and a DynamicFeatureSchema, but I had some problems (exceptions) with the FeatureSchema which did not handle every situations in OJ correctly (copying a layer, cloning, saving in a file, editing...) I think that having a FeatureSchema interface instead of a class would help...
> > This can be pretty efficient if suitable indexes are created for the > join condition to use. > > Dynamic joining to an in-memory layer should work fine for > dynamically-loaded datasources, too. It's only when both sides of the > join are loaded in a streaming fashion that it gets inefficient to > perform the join in the client. To make this efficient the join needs > to be sent to the underlying datastore - which of course requires both > join layers to be in the same datastore. And then things might get > harder, if it requires expression translation to convert the join > condition to the language understood by the datastore. > > I've been wrestling with this as well, because JEQL does this already. > But it has a slightly easier problem, because it doesn't have to worry > about redrawing a screenful of data. In JEQL the general rule is that > the driving (left-hand) layer (table) of the join can be streamed, but > the one or more child join tables should be in-memory to give good > performance. This is equivalent to what I outlined above. Assuming that the layer which contains the geometry and the key for the join is in memory would be a reasonnable target. > I have had thoughts about linking JEQL to JUMP, with one of the goals to > support this kind of capability.... But finding time is always an issue. Would be great ;-) Michaël > > Martin > > > > > On 10/4/2012 4:05 PM, Stefan Steiniger wrote: >> thanks for the input Michael. >> Lets hope Martin reads this? >> >> stefan >> >> Am 04.10.12 16:58, schrieb Michaël Michaud: >>> Hi >>>> with respect to Bernds request (He actually wants a "link"). >>>> >>>> Does anybody know if we can do links, like DB table joins? >>>> C >>> I think this is possible, and would be an interesting project. >>> If someone is interested, I think the most useful classes in OJ >>> are abstract class DataSource, and its implementation like >>> DataStoreDataSource or DataStoreQueryDataSource. >>> Difficulty may depends on the type of synchronization : >>> - from table to FeatureCollection only or bi-directionnal >>> - on load only or at every change >>> ... >>> >>> my 2 cents, >>> >>> Michaël >>>> ould it be that the Feature-Model of OJ restricts that.. as this would >>>> need to be defined somewhere in the FeatureSchema? >>>> What do you think? >>>> >>>> cheers >>>> stefan >>>> >>>> ------------------------------------------------------------------------------ >>>> Don't let slow site performance ruin your business. Deploy New Relic APM >>>> Deploy New Relic app performance management and know exactly >>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app >>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too! >>>> http://p.sf.net/sfu/newrelic-dev2dev >>>> _______________________________________________ >>>> Jump-pilot-devel mailing list >>>> Jump-pilot-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>> >>>> >>> ------------------------------------------------------------------------------ >>> Don't let slow site performance ruin your business. Deploy New Relic APM >>> Deploy New Relic app performance management and know exactly >>> what is happening inside your Ruby, Python, PHP, Java, and .NET app >>> Try New Relic at no cost today and get our sweet Data Nerd shirt too! >>> http://p.sf.net/sfu/newrelic-dev2dev >>> _______________________________________________ >>> Jump-pilot-devel mailing list >>> Jump-pilot-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> >> ------------------------------------------------------------------------------ >> Don't let slow site performance ruin your business. Deploy New Relic APM >> Deploy New Relic app performance management and know exactly >> what is happening inside your Ruby, Python, PHP, Java, and .NET app >> Try New Relic at no cost today and get our sweet Data Nerd shirt too! >> http://p.sf.net/sfu/newrelic-dev2dev >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2012.0.2221 / Virus Database: 2441/5309 - Release Date: 10/04/12 >> >> >> > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
