Niclas Hedhman wrote: > On Thursday 05 June 2008 12:25, Richard Wallace wrote: > >> Ok, so I took my first real look at the EntityStore APIs and I don't >> think you'd be able to shoehorn in Hibernate or another ORM like it >> easily. The best I can think of is if you dynamically generated a >> persistent entity class from the ComponentDescriptor and used that for >> persistence. >> > > Yeah, we kind of "don't wanna go there"... >
Ya I don't blame you. > >> OTOH it would be fairly easy to fit the OfBiz Entity Engine in. >> > > Ooook... (?) > Sorry for that obscure reference. I work at Atlassian and JIRA uses the OfBiz Entity Engine for it's persistence. It has a similar structure to it where it doesn't persist actual entities, but GenericValues which are pretty much just maps of the object data. > >> But I also looked more at the IBatis store and that makes the most >> sense of all to me now if you're going to be storing to an RDBMS. >> > > IBatis EntityStore has been started on, and I think both Edward and Michael > are working on it. Join in if you like. > > >> Also, storing >> to something like HBase would be almost trivial or other BigTable, >> column-based, database. I kinda like that idea. >> > > That is the main target. In principle, an ID refers to one Map of properties > and one Map of associations. > > >> One question I still have about the separation of the search and >> persistence is doing data aggregation and reporting. In one system I >> worked on trying to generate a report from a Lucene index with 10's of >> thousands of entries took several minutes. >> > > Was that an unstructured data setup? And what store was backing Lucene? > > The data was actually very structured. It was actually just page accesses. I have no idea why it was originally decided to throw it into Lucene (backed with a file-based index), but it wouldn't have been my first choice. >> When I did a spike to see >> how long it would take to generate the same report from the data in a >> relational database using an SQL query, it took only a few seconds. >> > > Nothing prevents us from creating an indexing system using JDBC. In fact, I > expect that to "show up" on the radar sooner or later. > > >> I'm wondering what would be the best way of generating this type of >> aggregated, report type data in Qi4j. >> > > What was done in SiteVision, and which I think we should do soon here, was > a "SQL Replicator". Essentially an asynchronous sideeffect of EntityStores > which pushed the data to RDBMSes. Then people can do data mining over there > as much as they want without disturbing the main application's performance. > > > Cheers > That's very interesting. It would be really cool to do that and then you could use whatever tool for generating reports you wanted. If you've got a lot of data you can use an OLAP server like Mondrian, otherwise maybe just use plain old JDBC or another reporting tool. And since all you have to worry about are inserts, updates and deletes that makes it much easier than a full ORM tool. So when can we expect that? ;) Rich _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
