svg changes: CLSQL and deployment example
Stephen Compall
> - make clsql store thread safe
> - add initial primitive support for application deployment. Currently
> SBCL and Gentoo relative.
Re the second item:
* Having separate copies of the static files is too much of a
maintenance pain. This deployment example should be purely
generated, not included in the repo.
* If you want to add simple new utility functions, please add them to
src/utils (being sure to use the new wexport function where
appropriate) instead of new packages and ASDF systems. If your
utilities are sufficiently complex to have their own ASDF system,
please distribute them separately, or try to get them integrated with
another package, and suggest that Weblocks depend on said separate
package.
It would be too confusing for users for ASDF systems like
`clsql-connection-pool' or `assoc-ref' to load from the Weblocks
tree. Anyway, we aren't afraid of adding new dependencies when they
bring value to the system.¹
If you opt to distribute any of these as new projects, distributing
via Bitbucket is sufficient, perhaps with a simple Bitbucket wiki
page as the project homepage, and a CLiki link to it.
Aside from the point about clsql-connection-pool, I haven't looked too
closely at your other change yet.
¹ http://failex.blogspot.com/2008/08/dependencies-versus-effort.html
--
I write stuff at http://failex.blogspot.com/ now. But the post
formatter and themes are terrible for sharing code, the primary
content, so it might go away sooner or later.
Yarek Kowalik
seperate package that needs to be loaded instead of a direct change to
the code base? CLSQL is not thread safe, but the connection pool
solves that.
I see no reason why Weblocks would not benefit from having the
connection pool changes integrated - I don't think we need a separate
(and thus optional) package. Anyone using an app that uses clsql
would need it, including weblcks-clsql-demo.
Yarek
Stephen Compall
> I see no reason why Weblocks would not benefit from having the
> connection pool changes integrated - I don't think we need a separate
> (and thus optional) package.
It's not fair to only consider Weblocks—if the changes are not
Weblocks-specific, but rather, useful to all CLSQL users who are also
using threads, then non-Weblocks CLSQL users would benefit from the
connection pool implementation. The big hint is that svg chose to put
the bulk of code in a separate ASDF system.
--
I write stuff at http://failex.blogspot.com/ now. But the post
Yarek Kowalik
the code. I see the need for a separate package, and the need to
break it out of the Weblocks code base.
Is there a reason why clsql connection pool cannot be integrated into
clsql itself? After all it already does some "fixes" to it (see clsql-
fixes.lisp), and I would imagine most anyone using cls
I'm going to transplant over the clsql connection pool change-set in
my branch and try it out with my app.
Yarek
On Dec 23, 11:00 am, Stephen Compall <s...@member.fsf.org> wrote:
> > I see no reason why Weblocks would not benefit from having the
> > connection pool changes integrated - I don't think we need a separate
> > (and thus optional) package.
>
> It's not fair to only consider Weblocks—if the changes are not
> Weblocks-specific, but rather, useful to all CLSQL users who are also
> using threads, then non-Weblocks CLSQL users would benefit from the
> connection pool implementation. The big hint is that svg chose to put
> the bulk of code in a separate ASDF system.
>
> --
Yarek Kowalik
> Is there a reason why clsql connection pool cannot be integrated into
> clsql itself? After all it already does some "fixes" to it (see clsql-
> fixes.lisp), and I would imagine most anyone using cls
>
code".
Yarek
Stephen Compall
> Is there a reason why clsql connection pool cannot be integrated into
> clsql itself?
There is another reason that it must be done by integration. Instances
of standard-db-object store the database used to fetch them, to be used
for functions like `update-records-from-instance' as the default
:database argument. This isn't a problem for uses of that function
directly within weblocks-clsql, because it always passes :database
explicitly, or does some other explicit manipulation (see
delete-persistent-object (database t) in svg).
However, join slots can be lazily fetched on first access, and the
usefulness of combining join slots with mixin views cannot be ignored.
At that point, we do not have the opportunity to specify what the
database to use should be. So CLSQL must be taught to
`find-process-database' in those instances.
On another issue: CLSQL already has "connection pools" in a more
traditional sense. So we must have a different name. I think
"repeatable per-thread" captures what's different about these pools.
Stephen Compall
> However, join slots can be lazily fetched on first access, and the
> usefulness of combining join slots with mixin views cannot be ignored.
> At that point, we do not have the opportunity to specify what the
> database to use should be. So CLSQL must be taught to
> `find-process-database' in those instances.
I've implemented this; see details on the ticket
http://weblocks.lighthouseapp.com/projects/18897-weblocks/tickets/61#ticket-61-4
and please try it out if you use the CLSQL backend in your webapps.
--
I write stuff at http://failex.blogspot.com/ now. But the post
Robin Lee Powell
>
> Stephen Compall <s11-IGUgQLVVQ...@public.gmane.org>
> writes:
> > However, join slots can be lazily fetched on first access, and
> > the usefulness of combining join slots with mixin views cannot
> > be ignored. At that point, we do not have the opportunity to
> > specify what the database to use should be. So CLSQL must be
> > taught to `find-process-database' in those instances.
>
> I've implemented this; see details on the ticket
> http://weblocks.lighthouseapp.com/projects/18897-weblocks/tickets/61#ticket-61-4
> and please try it out if you use the CLSQL backend in your
> webapps.
That's a lot of patches. Can you explain in small words what doing
all that will give me? The explanation on that page doesn't make
much sense to me, I'm afraid.
-Robin
--
They say: "The first AIs will be built by the military as weapons."
And I'm thinking: "Does it even occur to you to try for something
other than the default outcome?" -- http://shorl.com/tydruhedufogre
http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/
Stephen Compall
> That's a lot of patches. Can you explain in small words what doing
> all that will give me? The explanation on that page doesn't make
> much sense to me, I'm afraid.
I've set up a separate page for the CLSQL part at
http://common-lisp.net/project/clsql-fluid/
The thread safety thing: weblocks-clsql uses a single database object
(representing a connection) as the store object, and concurrent access
of a single connection is not supported. So if you use the CLSQL
backend, concurrent requests can screw things up randomly.
There are two reasons that I did it this way instead of copying svg's
code:
1. If you're using *default-store*, *MY-store*, or
clsql:*default-database* as a database object in your code, this
version requires no application changes to get full thread safety,
except to bind clsql:*default-database* to the store (more on that
momentarily).
2. DB-backed objects have their creating database stored in a hidden
slot. If you use things like the join-slots (you really have to read
up on clsql:def-view-class to know what this is), you have to use
the stored database. This change encapsulates the thread safety in
that stored database.
hfsbo.com is now running with these changes, so we'll see how they go in
action. If bordeaux-threads maintainers reject the fluid API, it can
just be added to clsql-fluid. I expect clsql-fluid to be maintained
separately indefinitely.
About clsql:*default-database*: weblocks-clsql doesn't call
clsql:connect anymore, so *default-database* doesn't get set to the
resulting database. I think this change is good, because relying on it
is a good way to break one of two DB-backed webapps when they run
together. If you use it (as I do), it's easy to bind it in an
:around-method on handle-client-request; anyway, if there are serious
objections to this, I'll add the old behavior back.
--
You know...
Stephen Compall
> Robin Lee Powell <rlpowell-VkGw2YyLwTCa/A/roGhosh2...@public.gmane.org> writes:
> The thread safety thing: weblocks-clsql uses a single database object
> (representing a connection) as the store object, and concurrent access
> of a single connection is not supported. So if you use the CLSQL
> backend, concurrent requests can screw things up randomly.
By "screw things up randomly", I include "cause a 500 on all future
requests, requiring the store to be restarted".