On Jun 8, 11:23 pm, "Leslie P. Polzer" <[email protected]>
wrote:
> 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.
OK, I might try DEFINE-SYMBOL-MACRO first. I didn't know about it, as
have based my lisp knowledge on CLTL2 - it's not in there!
>
> > 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.
The demo may have just started as a clone of the CLSQL demo I guess.
I think the Elephant demo should be able to use inheritance - more
exploration to come.
> > 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.
>
Certainly with CLSQL - haven't yet tried Elephant's postmodern
interface: it could well work better as it was purpose-built for
PostgreSQL.
> > I think Elephant would fare better, but with complexities in
> > querying. This thread:
> >http://groups.google.com/group/weblocks/browse_thread/thread/4a264044...
> > 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.
>
Agreed - would propose limiting the CLSQL demo to MySQL in the
examples, and use Elephant with PostgreSQL and its other back end
stores as earlier suggested.
> > 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.
>
OK, that makes sense until weblocks-elephant develops further.
> 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
-~----------~----~----~----~------~----~------~--~---
