On Jun 4, 2:40 am, "Leslie P. Polzer" <[email protected]>
wrote:
> Chris Hallwright wrote:
> > Probably me being daft instead, but the sandbox variant relies on a
> > macro to access a hunchentoot session value at run-time in place of
> > *default-store* in overriding the class-store method in sandbox.lisp,
> > and also in all-companies in the company model. I would want a way to
> > only have code in stores.lisp to have the same effects in order to
> > merge the memory/session-state version with persistent object
> > versions. I wouldn't want to have references to sandbox-store at all
> > (except maybe in stores.lisp), if the persistent object and memory
> > versions of the demo were to be combined. Not sure how to do that.
> > It would mean *default-store* acting like the macro-expansion of
> > (sandbox-store) as defined in weblocks-demo.lisp somehow.
>
> Alright, I took a look at the code so I'm now in a position
> to grasp what's going on. Sorry for not doing so earlier.
>
> I haven't used the memory store much far but if it requires trickery
> like that then we should fix it so the demo is able to act more like
> other stores.
>
> How about passing two functions to the memory store at initialization
> time, one setter and one getter? Would that be possible? Of course
> the memory store would then have to return a CLOS object to record
> those parameters.
>
> After that we could merge sandbox/memory and the other stores.
>
OK I'll look into that. I agree the goal should be to merge sandbox/
memory with the others, so will try a few ways and advise.
> > Yes, my issue is with the underlying RDBMS, not with CLSQL or
> > Elephant. MySQL doesn't support inheritance, as far as I can tell.
> > PostgreSQL does. Without inheritance you have very different
> > models, so I thought that warranted different versions of the demo.
> > PostgreSQL could be used with or without inheritance, MySQL only
> > without it.
>
> How about adding a new store backend for Postgres' object facilities
> then?
So there would be an object version, a relational version (for MySQL
users) and an object-relational version (for users of PostgreSQL's
object facilities)?
I was going to try to include the last version with the object
version, if at al possible.
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?
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
