Chris Hallwright wrote:
> After a bit of experimentation, and with only limited knowledge of the > internals of weblocks, clsql, and elephant, I'm hitting obstacles that > are preventing me from combining the demos as I'd hoped. By combining > the demos, I meant to only have changes between versions in the stores > code. Yes, that would be best. > Within weblocks-demo I looked into combining the scratch/session and > prevalence persistence stores in a smooth way - i.e. without the > current sandbox-store macro dotted through the code, and without > changing internals of weblocks memory and/or prevalence store. No > obvious way - if *default-store* could act like the (sandbox-store) > macro at run time, I could have done it, but symbols and macros aren't > interchangeable that way - would need a *special* variable form of > symbol-macrolet or something like that. You could use DEFINE-SYMBOL-MACRO, but I still think the right way would be changing the memory store to be more flexible. > I also tried using CLSQL's inheritance features (i.e. def-view-class > with superclasses) with PostgreSQL which also boasts some inheritance > capabilities, to reproduce the model structure of weblocks-demo > including the person superclass, instead of dropping person altogether > and merging its slots into employee as the CLSQL and Elephant versions > of the demo do. I wonder why the Elephant demo does that, since it works just fine with inheritance. > I found that using (def-view-class employee > (person) ...) simply caused PostgreSQL to repeat the inherited person > slots/columns in the employee table without using any of PostgreSQL's > table inheritance features at all. Yes, you'd need to write a special Postgres-OO backend to take advantage of these features. > I think Elephant would fare better, but with complexities in > querying. This thread: > http://groups.google.com/group/weblocks/browse_thread/thread/4a2640449816f48/5fab9b5e485a2922?lnk=gst&q=elephant+filter#5fab9b5e485a2922 > shows that Ian Eslick has already explored portable models and stores > - I understand that he concluded what I'm seeing too: that you really > need to tailor the model for the data store in weblocks. I concur to the overall opinion but also think that merging the Sandbox/Memory, Prevalence and Elephant demos is quite feasible and would benefit our store abstraction layer design. CLSQL is a special case because SQL maps so poorly to object orientation, so a separate demo for it is suitable. > It looks to me as though Elephant with various persistence back-end > stores is the most promising general-purpose data API for weblocks > object creation, but it would need more time spent on the object > manipulation side to round out its usefulness for querying in > weblocks. Yes, for example you can't easily sort on or query slots that are not indexed. But this can be done in memory as a first step. Leslie --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
