From marijnh at gmail.com  Tue Jan 28 18:37:47 2014
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Tue, 28 Jan 2014 19:37:47 +0100
Subject: "Auto-sync" questions
In-Reply-To: <CAJVWyAyYweeLN7C7_YO5m2HbCA4tWy8OjE3pV9Jkjhs-mXKx6w@mail.gmail.com>
References: <CAJVWyAyr7vbv5TppmREOkPgFKRDcvTszXNVeQwf+KAv4fmKc=Q@mail.gmail.com>
	<CAJnHWXuxpko0KcK1VxS-QR8OyQ7GWz6hUcTBk-9B-8KC7T_fpQ@mail.gmail.com>
	<CAJVWyAyYweeLN7C7_YO5m2HbCA4tWy8OjE3pV9Jkjhs-mXKx6w@mail.gmail.com>
Message-ID: <CAJnHWXsmbHGVjhyzi-996YDEiGMT8ZQB_b8rGu0snPXVdLFcFw@mail.gmail.com>

> Unfortunately I cannot rely on all access going through the writers
> specified in the slot definition. Unfortunately there is a great deal of
> existing code that uses (setf slot-value), with-slots, etc. in this
> codebase.

Ew. Sounds like sed or M-x replace-regexp might the most sane solution
to that particular problem.


From marijnh at gmail.com  Thu Jan 23 10:56:30 2014
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Thu, 23 Jan 2014 11:56:30 +0100
Subject: Suddenly having trouble with update-dao
In-Reply-To: <B80D0580-86F5-4D3D-A28D-46AAB149734A@gmail.com>
References: <CALEKj=vwVVg6+kKjpVpz9NfhN6LoOd7Nm2Ux49gxMbuiCeGVBQ@mail.gmail.com>
	<B80D0580-86F5-4D3D-A28D-46AAB149734A@gmail.com>
Message-ID: <CAJnHWXu289FBtVYJGVmuPqryPg3a8UsqwA81EWHg6O_nKSPs+g@mail.gmail.com>

Yes, recently someone submitted a patch that broke a bunch of things.
It has already been reverted in the git repository, but I guess
quicklisp picked up the broken version (since it seems to assume that
repositories are never broken). Update from git, I guess.

On Thu, Jan 23, 2014 at 9:07 AM, Colin Carr <colinpcarr at gmail.com> wrote:
> is update-dao in postmodern broken?
>  the strings are not being quoted
> Database error 42703: column "croatia" does not exist
>  QUERY: (SELECT * FROM country WHERE (name = Croatia)) From the html quickstart
> (let ((croatia (get-dao 'country "Croatia")))
>   (setf (country-inhabitants croatia) 4500000)
>   (update-dao croatia))
>
> On Jan 22, 2014, at 4:33 PM, Sabra Crolleton <sabra.crolleton at gmail.com> wrote:
>
>> After a recent quicklisp update, suddenly update-dao throws syntax errors. Simplest example:
>>
>> (update-dao (get-dao 'topic 182))
>>
>> throws the following error:
>>
>> Database error 42601: syntax error at or near "Border"
>> QUERY: UPDATE topics SET name = Cross Border Transactions, comments = NULL, usergroup_id = 1, permission_id = 1, parenttopic_id = 0 WHERE (id = 182)
>>    [Condition of type CL-POSTGRES-ERROR:SYNTAX-ERROR-OR-ACCESS-VIOLATION]
>>
>> I haven't updated anything and having a hard time trying to figure out what is triggering the problem. Anyone else seeing this or just me?
>>
>> Any pointers would be appreciated.
>>
>> Sabra
>
>


From xach at xach.com  Thu Jan 23 16:52:51 2014
From: xach at xach.com (Zach Beane)
Date: Thu, 23 Jan 2014 11:52:51 -0500
Subject: Suddenly having trouble with update-dao
In-Reply-To: <20140123162457.GB9356@seid-online.de> (Ralf Mattes's message of
	"Thu, 23 Jan 2014 17:24:57 +0100")
References: <CALEKj=vwVVg6+kKjpVpz9NfhN6LoOd7Nm2Ux49gxMbuiCeGVBQ@mail.gmail.com>
	<B80D0580-86F5-4D3D-A28D-46AAB149734A@gmail.com>
	<CAJnHWXu289FBtVYJGVmuPqryPg3a8UsqwA81EWHg6O_nKSPs+g@mail.gmail.com>
	<87k3dqagbw.fsf@zpob.site.sys> <20140123160227.GA9356@seid-online.de>
	<87eh3yacrm.fsf@zpob.site.sys> <20140123162457.GB9356@seid-online.de>
Message-ID: <8761paabdo.fsf@zpob.site.sys>

Ralf Mattes <rm at seid-online.de> writes:

> On Thu, Jan 23, 2014 at 11:22:53AM -0500, Zach Beane wrote:
>> 
>> It does use arbitrary checkouts for many projects. There are many useful
>> projects for which that is the only way the software is made available.
>> 
>> Most of the time it works ok, but sometimes it doesn't. I'd like to
>> improve the situation, but it takes time.
>
> I see. 
> So, is there a way to install a specific quicklisp dist? 

http://blog.quicklisp.org/2011/08/going-back-in-dist-time.html describes
the current process. It can only be done after the initial install.
 
As it happens, in the next day or two I am going to update the
initial install process to make it easy to install a specific dist by
URL during installation rather than afterwards. 

This will extend to the Quicklisp software itself (i.e. asdf and the
code that fetches and loads library code). The goal is to make it easy
to have a stable, reproducible Quicklisp configuration.

> My buildscript currently uses the following:
>
>   sbcl --non-interactive --no-userinit --load quicklisp.lisp 
>   --eval "(quicklisp-quickstart:install :path (merge-pathnames \"quicklisp/\" (directory-namestring (truename *default-pathname-defaults*))))"
>
> But this seems to fetch the current quicklisp dist.
> And, related: how long do you provide older versions of the dist?

I hope to provide them indefinitely. The cost for Amazon storage for
Quicklisp is very low, currently around $5/month.

> Thanks for all that work - by using quicklisp I was able to drop
> thew need to create Debian wrappers for 12 lisp packages.

Glad to hear it.

(Further discussion should probably go to quicklisp at googlegroups.com
instead.)

Zach



From marijnh at gmail.com  Tue Jan 28 18:15:53 2014
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Tue, 28 Jan 2014 19:15:53 +0100
Subject: "Auto-sync" questions
In-Reply-To: <CAJVWyAyr7vbv5TppmREOkPgFKRDcvTszXNVeQwf+KAv4fmKc=Q@mail.gmail.com>
References: <CAJVWyAyr7vbv5TppmREOkPgFKRDcvTszXNVeQwf+KAv4fmKc=Q@mail.gmail.com>
Message-ID: <CAJnHWXuxpko0KcK1VxS-QR8OyQ7GWz6hUcTBk-9B-8KC7T_fpQ@mail.gmail.com>

Hi Eli,

I really want to stay as far away from the kind of magic that is
giving database abstactions a bad name. So I don't really think
*db-auto-sync* is a feature that fits in Postmodern.

Doesn't looping over the slots in your class, and defining :after
methods on their setters, solve this without touching the Postmodern
internals? It'll probably be awkward, as any MOP-based method
definition is bound to be, but I believe it should be possible.

Best,
Marijn

On Tue, Jan 28, 2014 at 5:11 PM, Eli Naeher <enaeher at gmail.com> wrote:
> Hello,
>
> I'm in the process of converting an existing application from CLSQL to
> Postmodern. This application makes heavy use of CLSQL's *db-auto-sync*
> feature, whereby new instances of view (DAO) classes are immediately
> inserted into the DB table, and changes to view class instance slots result
> in immediate updates.
>
> While I like the explicit approach of save-dao/update-dao/etc., there is
> just too much code in this application that relies on the auto-sync behavior
> to adopt that approach in the immediate term.
>
> So, a few questions:
>
> - would a *db-auto-sync*-like feature be accepted if I were to submit a pull
> request, or are there philosophical objections to having this feature in
> mainline Postmodern?
>
> - if this feature is not desired, would you be willing to accept a few
> patches that would make it easier for me to build this feature as a separate
> third-party library? Specifically, I'm thinking of something like CLSQL's
> *db-deserializing* flag, which would indicate to my code when it is being
> called by a dao-row-reader (and thus should not propagate slot value changes
> to the database) vs when it is being called by user code.
>
> Thank you,
> -Eli


From mb at bese.it  Wed Jan 29 23:33:53 2014
From: mb at bese.it (Marco Baringer)
Date: Thu, 30 Jan 2014 00:33:53 +0100
Subject: on removing build-dao-methods
Message-ID: <87bnyujrby.fsf@locaine.bese.it>


i'd like to replace build-dao-methods with a set of slots on the
dao-class instance, a common root in the class hierarchy (which would be
dao-object) and a set of methods specialized on dao-object. before i do
the work i want to make sure the patch won't be rejected on principle.

my main problem with build-dao-methods is that it generates a new,
distinct, method on the generic functions for every dao-class instance.
when you have a lot of dao-class instances it becomes difficult to
figure out which methods are auto generated and which are 'real' and may
do something different than the standard methods (and implementing these
non standard methods requires rewriting a lot of the code in
build-dao-methods since call-next-method doesn't actually do
anything).

another problem, though i haven't actually had this problem in practice,
is that build-dao-methods defines shared-initialize :after method on the
given class to call fetch-defaults; this makes it impossible for me to
define my own shared-initialize :after method to perform whatever extra
initialization i may have. i can imagine a work around to this issue by
defining the dao-class and then subclassing it to get the actual
functionality i need, or call fetch-defaults myself, but being able to
just define an :after method and have things Just Work(TM) seems
simpler.

there are a few things the build-dao-methods does that, i think, i can
maintain using just the plain old mop:

1. only defining update-dao and upsert-dao when the class has value
   fields. by inspecting the class at compute-class-precedence-list time
   we can inject either dao-value-object or dao-key-only-object and then
   define the update/upsert-dao methods on dao-value-object and not
   dao-key-only-object.

   fwiw i think these methods should be defined for all dao objects;
   just because all the slots of the object are its primary key doesn't
   mean that changing one of those slots doesn't make sense (this can
   happen in practice when working with relation tables whose columns
   are all foreign keys and to preserve uniqueness of the relation the
   primary key consists of all (usually 2) columns).

2. the methods defined by build-dao-methods close over a set of
   precomputed values (column names and sql templates). by storing these
   values in the class instance directly we still avoid recomputing them
   every time the method is called and gain the ability to, easily,
   inspect their values at run time for debugging purposes.

the one thing build-dao-methods does that i can't maintain is the lack
of a common root class for all dao-class instances (in order for the
various update/get/upsert/insert dao methods to get called there will
need to be a dao-object in the hierarchy somewhere). the dao-object
class can be injected in dao-class instance's precedence-list via
compute-class-precedence-list, so there wouldn't be any changes required
to user code; i don't really see this as an issue.

i would also need to add in a dependency on closer-mop. i could imagine
just cut 'n pasting the, relatively limited, parts of closer-mop we'd
actually be using, and that would keep postmodern's dependencies to what
they are today, but that seems like a bad thing to do.

since this is a substantial change to how the dao methods are created
i'd like to make sure that there aren't any objects to it (philosophical
or technical) before actually making the change and submitting the pull
request.

thanks,
-- 
-marco


From xach at xach.com  Thu Jan 23 15:05:55 2014
From: xach at xach.com (Zach Beane)
Date: Thu, 23 Jan 2014 10:05:55 -0500
Subject: Suddenly having trouble with update-dao
In-Reply-To: <CAJnHWXu289FBtVYJGVmuPqryPg3a8UsqwA81EWHg6O_nKSPs+g@mail.gmail.com>
	(Marijn Haverbeke's message of "Thu, 23 Jan 2014 11:56:30 +0100")
References: <CALEKj=vwVVg6+kKjpVpz9NfhN6LoOd7Nm2Ux49gxMbuiCeGVBQ@mail.gmail.com>
	<B80D0580-86F5-4D3D-A28D-46AAB149734A@gmail.com>
	<CAJnHWXu289FBtVYJGVmuPqryPg3a8UsqwA81EWHg6O_nKSPs+g@mail.gmail.com>
Message-ID: <87k3dqagbw.fsf@zpob.site.sys>

Marijn Haverbeke <marijnh at gmail.com> writes:

> Yes, recently someone submitted a patch that broke a bunch of things.
> It has already been reverted in the git repository, but I guess
> quicklisp picked up the broken version (since it seems to assume that
> repositories are never broken). Update from git, I guess.

I don't assume that repositories are never broken. I don't have a good
system in place to do pre-release testing beyond "Does it build?" I'd
like to do more thorough testing, but setting up the infrastructure for
it takes time.

The easiest short-term fix is something like:

  cd ~/quicklisp/local-projects
  git clone https://github.com/marijnh/Postmodern.git

Another option is to go back to the previous dist via the instructions
in http://blog.quicklisp.org/2011/08/going-back-in-dist-time.html.

Sorry for the inconvenience. The fixed dist will be available in
early February.

Zach


From rm at seid-online.de  Thu Jan 23 16:02:27 2014
From: rm at seid-online.de (Ralf Mattes)
Date: Thu, 23 Jan 2014 17:02:27 +0100
Subject: Suddenly having trouble with update-dao
In-Reply-To: <87k3dqagbw.fsf@zpob.site.sys>
References: <CALEKj=vwVVg6+kKjpVpz9NfhN6LoOd7Nm2Ux49gxMbuiCeGVBQ@mail.gmail.com>
 <B80D0580-86F5-4D3D-A28D-46AAB149734A@gmail.com>
 <CAJnHWXu289FBtVYJGVmuPqryPg3a8UsqwA81EWHg6O_nKSPs+g@mail.gmail.com>
 <87k3dqagbw.fsf@zpob.site.sys>
Message-ID: <20140123160227.GA9356@seid-online.de>

On Thu, Jan 23, 2014 at 10:05:55AM -0500, Zach Beane wrote:
> Marijn Haverbeke <marijnh at gmail.com> writes:
> 
> > Yes, recently someone submitted a patch that broke a bunch of things.
> > It has already been reverted in the git repository, but I guess
> > quicklisp picked up the broken version (since it seems to assume that
> > repositories are never broken). Update from git, I guess.

Urghs, I just created some (Debian) package building scripts that rely
on Quicklisp (i.e. that install a temporsry quicklisp to build standalone
binaries). The idea that quicklisp might deploy some arbitrary checkout 
makes me frown.
 
> I don't assume that repositories are never broken. I don't have a good
> system in place to do pre-release testing beyond "Does it build?" I'd
> like to do more thorough testing, but setting up the infrastructure for
> it takes time.

It might be a good idea to offer the upstream programmers a way to provide
a branch/tag to mark quicklisp ready versions of the code (I personally use
git-flow and that has a branch named 'release').

Cheers, Ralf Mattes



From xach at xach.com  Thu Jan 23 16:22:53 2014
From: xach at xach.com (Zach Beane)
Date: Thu, 23 Jan 2014 11:22:53 -0500
Subject: Suddenly having trouble with update-dao
In-Reply-To: <20140123160227.GA9356@seid-online.de> (Ralf Mattes's message of
	"Thu, 23 Jan 2014 17:02:27 +0100")
References: <CALEKj=vwVVg6+kKjpVpz9NfhN6LoOd7Nm2Ux49gxMbuiCeGVBQ@mail.gmail.com>
	<B80D0580-86F5-4D3D-A28D-46AAB149734A@gmail.com>
	<CAJnHWXu289FBtVYJGVmuPqryPg3a8UsqwA81EWHg6O_nKSPs+g@mail.gmail.com>
	<87k3dqagbw.fsf@zpob.site.sys> <20140123160227.GA9356@seid-online.de>
Message-ID: <87eh3yacrm.fsf@zpob.site.sys>

Ralf Mattes <rm at seid-online.de> writes:

> On Thu, Jan 23, 2014 at 10:05:55AM -0500, Zach Beane wrote:
>> Marijn Haverbeke <marijnh at gmail.com> writes:
>> 
>> > Yes, recently someone submitted a patch that broke a bunch of things.
>> > It has already been reverted in the git repository, but I guess
>> > quicklisp picked up the broken version (since it seems to assume that
>> > repositories are never broken). Update from git, I guess.
>
> Urghs, I just created some (Debian) package building scripts that rely
> on Quicklisp (i.e. that install a temporsry quicklisp to build standalone
> binaries). The idea that quicklisp might deploy some arbitrary checkout 
> makes me frown.

It does use arbitrary checkouts for many projects. There are many useful
projects for which that is the only way the software is made available.

Most of the time it works ok, but sometimes it doesn't. I'd like to
improve the situation, but it takes time.
  
>> I don't assume that repositories are never broken. I don't have a good
>> system in place to do pre-release testing beyond "Does it build?" I'd
>> like to do more thorough testing, but setting up the infrastructure for
>> it takes time.
>
> It might be a good idea to offer the upstream programmers a way to provide
> a branch/tag to mark quicklisp ready versions of the code (I personally use
> git-flow and that has a branch named 'release').

Not a lot of Quicklisp-provided projects follow this convention, but
when they do, I try to use it.

Zach


From sabra.crolleton at gmail.com  Thu Jan 23 15:43:02 2014
From: sabra.crolleton at gmail.com (Sabra Crolleton)
Date: Thu, 23 Jan 2014 07:43:02 -0800
Subject: Suddenly having trouble with update-dao
In-Reply-To: <CAJnHWXu289FBtVYJGVmuPqryPg3a8UsqwA81EWHg6O_nKSPs+g@mail.gmail.com>
References: <CALEKj=vwVVg6+kKjpVpz9NfhN6LoOd7Nm2Ux49gxMbuiCeGVBQ@mail.gmail.com>
	<B80D0580-86F5-4D3D-A28D-46AAB149734A@gmail.com>
	<CAJnHWXu289FBtVYJGVmuPqryPg3a8UsqwA81EWHg6O_nKSPs+g@mail.gmail.com>
Message-ID: <CALEKj=vsJA72L3yONVp03Q6PPt5Rf0Nrb8Hgge-pit0SHQhpqw@mail.gmail.com>

Thank you for the confirmation. I thought I was losing my mind.

Sabra


On Thu, Jan 23, 2014 at 2:56 AM, Marijn Haverbeke <marijnh at gmail.com> wrote:

> Yes, recently someone submitted a patch that broke a bunch of things.
> It has already been reverted in the git repository, but I guess
> quicklisp picked up the broken version (since it seems to assume that
> repositories are never broken). Update from git, I guess.
>
> On Thu, Jan 23, 2014 at 9:07 AM, Colin Carr <colinpcarr at gmail.com> wrote:
> > is update-dao in postmodern broken?
> >  the strings are not being quoted
> > Database error 42703: column "croatia" does not exist
> >  QUERY: (SELECT * FROM country WHERE (name = Croatia)) From the html
> quickstart
> > (let ((croatia (get-dao 'country "Croatia")))
> >   (setf (country-inhabitants croatia) 4500000)
> >   (update-dao croatia))
> >
> > On Jan 22, 2014, at 4:33 PM, Sabra Crolleton <sabra.crolleton at gmail.com>
> wrote:
> >
> >> After a recent quicklisp update, suddenly update-dao throws syntax
> errors. Simplest example:
> >>
> >> (update-dao (get-dao 'topic 182))
> >>
> >> throws the following error:
> >>
> >> Database error 42601: syntax error at or near "Border"
> >> QUERY: UPDATE topics SET name = Cross Border Transactions, comments =
> NULL, usergroup_id = 1, permission_id = 1, parenttopic_id = 0 WHERE (id =
> 182)
> >>    [Condition of type
> CL-POSTGRES-ERROR:SYNTAX-ERROR-OR-ACCESS-VIOLATION]
> >>
> >> I haven't updated anything and having a hard time trying to figure out
> what is triggering the problem. Anyone else seeing this or just me?
> >>
> >> Any pointers would be appreciated.
> >>
> >> Sabra
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/postmodern-devel/attachments/20140123/e447aac3/attachment.html>

From attila.lendvai at gmail.com  Thu Jan  2 10:32:19 2014
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Thu, 2 Jan 2014 16:32:19 +0600
Subject: Simple-date vs local-time
In-Reply-To: <CAJVWyAzTL15f-ARKxYaiofTVSOp+trx_jQ+uqryNN0tODD+Kqw@mail.gmail.com>
References: <CAJVWyAzTL15f-ARKxYaiofTVSOp+trx_jQ+uqryNN0tODD+Kqw@mail.gmail.com>
Message-ID: <CAE4vfcJ5+-ZOoLm0M-wEc-N06gmm9pv_420kXmFJFgvyr7mBYw@mail.gmail.com>

> are stored as "timestamp without time zone," but we are hoping to move
> toward a timezone-aware model at some point down the road (although not
> immediately--it might end up being a couple years).

just a quick note that local-time timestamps are also not aware of
timezones either, and that is fine that way. only the conversion
functions are aware of timezones, e.g. when printing a timestamp into
a calendar system defined string of characters that humans can
understand, or when e.g. creating a timestamp from user input.

also note that local-time has quite some TODO's documented in its TODO
file. but other than that it works.

https://github.com/dlowe-net/local-time/blob/master/TODO.org

-- 
? attila lendvai
? PGP: 963F 5D5F 45C7 DFCD 0A39
--
?People focus on role models; it is more effective to find antimodels
- people you don't want to resemble when you grow up.?
	? Nassim Taleb (1960?)


From colinpcarr at gmail.com  Thu Jan 23 16:41:12 2014
From: colinpcarr at gmail.com (Colin Carr)
Date: Thu, 23 Jan 2014 11:41:12 -0500
Subject: Suddenly having trouble with update-dao
In-Reply-To: <87k3dqagbw.fsf@zpob.site.sys>
References: <CALEKj=vwVVg6+kKjpVpz9NfhN6LoOd7Nm2Ux49gxMbuiCeGVBQ@mail.gmail.com> <B80D0580-86F5-4D3D-A28D-46AAB149734A@gmail.com> <CAJnHWXu289FBtVYJGVmuPqryPg3a8UsqwA81EWHg6O_nKSPs+g@mail.gmail.com> <87k3dqagbw.fsf@zpob.site.sys>
Message-ID: <AAD3C325-2533-4EEF-8ECE-DC3DB60D2AE7@gmail.com>

Thank you sir!

- C

(Eos:run! :postmodern)
..............................
 Did 65 checks.
    Pass: 65 (100%)
    Skip: 0 ( 0%)
    Fail: 0 ( 0%)
On Jan 23, 2014, at 10:05 AM, Zach Beane <xach at xach.com> wrote:

> Marijn Haverbeke <marijnh at gmail.com> writes:
> 
>> Yes, recently someone submitted a patch that broke a bunch of things.
>> It has already been reverted in the git repository, but I guess
>> quicklisp picked up the broken version (since it seems to assume that
>> repositories are never broken). Update from git, I guess.
> 
> I don't assume that repositories are never broken. I don't have a good
> system in place to do pre-release testing beyond "Does it build?" I'd
> like to do more thorough testing, but setting up the infrastructure for
> it takes time.
> 
> The easiest short-term fix is something like:
> 
>  cd ~/quicklisp/local-projects
>  git clone https://github.com/marijnh/Postmodern.git
> 
> Another option is to go back to the previous dist via the instructions
> in http://blog.quicklisp.org/2011/08/going-back-in-dist-time.html.
> 
> Sorry for the inconvenience. The fixed dist will be available in
> early February.
> 
> Zach
> 



From enaeher at gmail.com  Tue Jan 28 16:11:38 2014
From: enaeher at gmail.com (Eli Naeher)
Date: Tue, 28 Jan 2014 10:11:38 -0600
Subject: "Auto-sync" questions
Message-ID: <CAJVWyAyr7vbv5TppmREOkPgFKRDcvTszXNVeQwf+KAv4fmKc=Q@mail.gmail.com>

Hello,

I'm in the process of converting an existing application from CLSQL to
Postmodern. This application makes heavy use of CLSQL's *db-auto-sync*
feature, whereby new instances of view (DAO) classes are immediately
inserted into the DB table, and changes to view class instance slots result
in immediate updates.

While I like the explicit approach of save-dao/update-dao/etc., there is
just too much code in this application that relies on the auto-sync
behavior to adopt that approach in the immediate term.

So, a few questions:

- would a *db-auto-sync*-like feature be accepted if I were to submit a
pull request, or are there philosophical objections to having this feature
in mainline Postmodern?

- if this feature is not desired, would you be willing to accept a few
patches that would make it easier for me to build this feature as a
separate third-party library? Specifically, I'm thinking of something like
CLSQL's *db-deserializing* flag, which would indicate to my code when it is
being called by a dao-row-reader (and thus should not propagate slot value
changes to the database) vs when it is being called by user code.

Thank you,
-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/postmodern-devel/attachments/20140128/d117c2f4/attachment.html>

From colinpcarr at gmail.com  Thu Jan 23 08:07:28 2014
From: colinpcarr at gmail.com (Colin Carr)
Date: Thu, 23 Jan 2014 03:07:28 -0500
Subject: Suddenly having trouble with update-dao
In-Reply-To: <CALEKj=vwVVg6+kKjpVpz9NfhN6LoOd7Nm2Ux49gxMbuiCeGVBQ@mail.gmail.com>
References: <CALEKj=vwVVg6+kKjpVpz9NfhN6LoOd7Nm2Ux49gxMbuiCeGVBQ@mail.gmail.com>
Message-ID: <B80D0580-86F5-4D3D-A28D-46AAB149734A@gmail.com>

is update-dao in postmodern broken? 
 the strings are not being quoted
Database error 42703: column "croatia" does not exist
 QUERY: (SELECT * FROM country WHERE (name = Croatia)) From the html quickstart
(let ((croatia (get-dao 'country "Croatia")))
  (setf (country-inhabitants croatia) 4500000)
  (update-dao croatia))

On Jan 22, 2014, at 4:33 PM, Sabra Crolleton <sabra.crolleton at gmail.com> wrote:

> After a recent quicklisp update, suddenly update-dao throws syntax errors. Simplest example:
> 
> (update-dao (get-dao 'topic 182))
> 
> throws the following error:
> 
> Database error 42601: syntax error at or near "Border"                                                                                                     
> QUERY: UPDATE topics SET name = Cross Border Transactions, comments = NULL, usergroup_id = 1, permission_id = 1, parenttopic_id = 0 WHERE (id = 182)
>    [Condition of type CL-POSTGRES-ERROR:SYNTAX-ERROR-OR-ACCESS-VIOLATION]
> 
> I haven't updated anything and having a hard time trying to figure out what is triggering the problem. Anyone else seeing this or just me?
> 
> Any pointers would be appreciated.
> 
> Sabra



From sabra.crolleton at gmail.com  Wed Jan 22 21:33:13 2014
From: sabra.crolleton at gmail.com (Sabra Crolleton)
Date: Wed, 22 Jan 2014 13:33:13 -0800
Subject: Suddenly having trouble with update-dao
Message-ID: <CALEKj=vwVVg6+kKjpVpz9NfhN6LoOd7Nm2Ux49gxMbuiCeGVBQ@mail.gmail.com>

After a recent quicklisp update, suddenly update-dao throws syntax errors.
Simplest example:

(update-dao (get-dao 'topic 182))

throws the following error:

Database error 42601: syntax error at or near "Border"


QUERY: UPDATE topics SET name = Cross Border Transactions, comments = NULL,
usergroup_id = 1, permission_id = 1, parenttopic_id = 0 WHERE (id = 182)
   [Condition of type CL-POSTGRES-ERROR:SYNTAX-ERROR-OR-ACCESS-VIOLATION]

I haven't updated anything and having a hard time trying to figure out what
is triggering the problem. Anyone else seeing this or just me?

Any pointers would be appreciated.

Sabra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/postmodern-devel/attachments/20140122/921944ec/attachment.html>

From enaeher at gmail.com  Tue Jan 28 18:34:21 2014
From: enaeher at gmail.com (Eli Naeher)
Date: Tue, 28 Jan 2014 12:34:21 -0600
Subject: "Auto-sync" questions
In-Reply-To: <CAJnHWXuxpko0KcK1VxS-QR8OyQ7GWz6hUcTBk-9B-8KC7T_fpQ@mail.gmail.com>
References: <CAJVWyAyr7vbv5TppmREOkPgFKRDcvTszXNVeQwf+KAv4fmKc=Q@mail.gmail.com>
	<CAJnHWXuxpko0KcK1VxS-QR8OyQ7GWz6hUcTBk-9B-8KC7T_fpQ@mail.gmail.com>
Message-ID: <CAJVWyAyYweeLN7C7_YO5m2HbCA4tWy8OjE3pV9Jkjhs-mXKx6w@mail.gmail.com>

Hello,

I definitely understand your concerns about magic here--I'd prefer the
explicit Postmodern approach for sure if I were starting from scratch.

Unfortunately I cannot rely on all access going through the writers
specified in the slot definition. Unfortunately there is a great deal of
existing code that uses (setf slot-value), with-slots, etc. in this
codebase.

Right now my approach is to use a (setf slot-value-using-class) :after
method, but of course this method fires when the dao-row-reader is first
populating the slots on a freshly-allocated instance after retrieving the
data from Postgres--hence my question about a *db-deserializing*-type flag.

Thank you,
-Eli



On Tue, Jan 28, 2014 at 12:15 PM, Marijn Haverbeke <marijnh at gmail.com>wrote:

> Hi Eli,
>
> I really want to stay as far away from the kind of magic that is
> giving database abstactions a bad name. So I don't really think
> *db-auto-sync* is a feature that fits in Postmodern.
>
> Doesn't looping over the slots in your class, and defining :after
> methods on their setters, solve this without touching the Postmodern
> internals? It'll probably be awkward, as any MOP-based method
> definition is bound to be, but I believe it should be possible.
>
> Best,
> Marijn
>
> On Tue, Jan 28, 2014 at 5:11 PM, Eli Naeher <enaeher at gmail.com> wrote:
> > Hello,
> >
> > I'm in the process of converting an existing application from CLSQL to
> > Postmodern. This application makes heavy use of CLSQL's *db-auto-sync*
> > feature, whereby new instances of view (DAO) classes are immediately
> > inserted into the DB table, and changes to view class instance slots
> result
> > in immediate updates.
> >
> > While I like the explicit approach of save-dao/update-dao/etc., there is
> > just too much code in this application that relies on the auto-sync
> behavior
> > to adopt that approach in the immediate term.
> >
> > So, a few questions:
> >
> > - would a *db-auto-sync*-like feature be accepted if I were to submit a
> pull
> > request, or are there philosophical objections to having this feature in
> > mainline Postmodern?
> >
> > - if this feature is not desired, would you be willing to accept a few
> > patches that would make it easier for me to build this feature as a
> separate
> > third-party library? Specifically, I'm thinking of something like CLSQL's
> > *db-deserializing* flag, which would indicate to my code when it is being
> > called by a dao-row-reader (and thus should not propagate slot value
> changes
> > to the database) vs when it is being called by user code.
> >
> > Thank you,
> > -Eli
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/postmodern-devel/attachments/20140128/d8d1737d/attachment.html>

From rm at seid-online.de  Thu Jan 23 16:24:57 2014
From: rm at seid-online.de (Ralf Mattes)
Date: Thu, 23 Jan 2014 17:24:57 +0100
Subject: Suddenly having trouble with update-dao
In-Reply-To: <87eh3yacrm.fsf@zpob.site.sys>
References: <CALEKj=vwVVg6+kKjpVpz9NfhN6LoOd7Nm2Ux49gxMbuiCeGVBQ@mail.gmail.com>
 <B80D0580-86F5-4D3D-A28D-46AAB149734A@gmail.com>
 <CAJnHWXu289FBtVYJGVmuPqryPg3a8UsqwA81EWHg6O_nKSPs+g@mail.gmail.com>
 <87k3dqagbw.fsf@zpob.site.sys>
 <20140123160227.GA9356@seid-online.de>
 <87eh3yacrm.fsf@zpob.site.sys>
Message-ID: <20140123162457.GB9356@seid-online.de>

On Thu, Jan 23, 2014 at 11:22:53AM -0500, Zach Beane wrote:
> 
> It does use arbitrary checkouts for many projects. There are many useful
> projects for which that is the only way the software is made available.
> 
> Most of the time it works ok, but sometimes it doesn't. I'd like to
> improve the situation, but it takes time.

I see. 
So, is there a way to install a specific quicklisp dist? 
My buildscript currently uses the following:

  sbcl --non-interactive --no-userinit --load quicklisp.lisp 
  --eval "(quicklisp-quickstart:install :path (merge-pathnames \"quicklisp/\" (directory-namestring (truename *default-pathname-defaults*))))"

But this seems to fetch the current quicklisp dist.
And, related: how long do you provide older versions of the dist?

Thanks for all that work - by using quicklisp I was able to drop
thew need to create Debian wrappers for 12 lisp packages.

 Cheers, RalfD