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.
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. 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 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. 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. 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. On Jun 4, 9:54 pm, Chris Hallwright <[email protected]> wrote: > On Jun 4, 4:25 pm, "Leslie P. Polzer" <[email protected]> > wrote: > > > Chris Hallwright wrote: > > > But just to be clear, are you OK with a separate relational (i.e. non- > > > object) version along the lines of the current CLSQL and Elephant > > > demos? I see that as essential because the models have to be > > > different -all of person's slots are in employee and there is no > > > person model in these "relational" versions because there's no > > > inheritance, with a ripple effect onto views as well. I can't see any > > > alternative to having a separate version (like the current CLSQL and > > > Elephant versions) for purely reklational database users (typically > > > MySQL). What do you think? > > > Fine in general, but I still don't get why the CLSQL version isn't > > enough... > > Sorry - yes, it is enough. I'm just thinking about how to break up > the demos differently from the current way. I think I'll just > experiment a bit first and see what I come up with. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
