You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<fortitude> eudoxia: with crane, did you intend to require a connected database to define new tables?
<eudoxia> fortitude: no, see https://github.com/eudoxia0/hermetic/blob/master/contrib/crane/crane.lisp
<eudoxia> fortitude: the creation of tables is deferred until the user calls build on them manually
<eudoxia> i think that's the right use of deferred
<fortitude> eudoxia: that's what I was expecting, but your fix for issue #5 broke it
<fortitude> wasn't sure what your intent was
<eudoxia> fortitude: i haven't touched hermetic's crane integration in a while, yeah, it's probably broken
<eudoxia> thanks for pointing that out, i'll take a look at it
<fortitude> eudoxia: the problem is in your mop finalization, you check to see if the db type is sqlite
<fortitude> seems like it could be tricky to fix
<eudoxia> fortitude: i think there might be a simple fix. moving the call to closer-mop:finalize-inheritance away from the deftable macro and to the build function
The text was updated successfully, but these errors were encountered:
Update: I've refactored the connection code so Crane knows about a table before connecting to it. However, I've yet to add the code to "defer" table creation until a connection to the proper database is acquired.
Sessions associate tables to databases, allowing both multiple concurrent connections and for table definitions to be decoupled from database definitions. This was one of the biggest problems with Crane 0.X, see #12, #43.
Introduced by #5.
Reported by fortitude on
#lisp
:The text was updated successfully, but these errors were encountered: