Robin Lee Powell <[email protected]> writes: > 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... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
