Signals

[Andy Mckay]

Just a general question on best practice.

On sites I need to know when something has changed for example:

- to fix up resolve/Uid

- to populate or remove from search

And so on.

Of course content mirror writes straight to the db, my application
knows nothing about the changes. This is easily solvable and I've done:

- a trigger on the content table change to write to an audit log and
then a cron job to look up what changed

- checking the modified date and comparing to last time cron job was run

And so on. But I was wondering should there be a mechanism for a http
web hook from plone to the front end "this has changed". Do you find
you need that?
--
Andy McKay
www.clearwind.ca

[Alan Runyan]

You can snap in collective.solr and voila. You will have SOLR
updated/remove as you would expect. Then simply query with solrpy
library.

I would suggest using content mirror and the CMS events system to handle
the changes.

When you say "fix up resolve/$uid" what do you mean? Kapil beat me into
submission in agreeing that exposing resolveuid/$uid in content is
bearable.

Audit logging is a very simple extension to contentmirror. Would be
nice to have a cmirror.auditlog (I have some prototype code but its very
easy). In fact, shouldnt we pick a namespace? cmirror, mirror,
contentmirror? I'm fine with keeping ore. But kinda sucks ;-( as its
extra 4 things.

You could wire a subscriber to collective.indexing really easily; which
could do some URL stuff.

NOTE: Kapil really wants to land a contentmirror.async mode before 1.0.
So some of this stuff may not be compatible with that functionality.

Cheers
Alan

[Andy Mckay]

On 1-Apr-09, at 11:15 AM, Alan Runyan wrote:

> You can snap in collective.solr and voila. You will have SOLR
> updated/remove as you would expect. Then simply query with solrpy
> library.

Solr is an option for some, but not all. For example spitting Plone
out to cheap web hosts or GAE.

> I would suggest using content mirror and the CMS events system to
> handle
> the changes.

Not sure I follow you there.

> When you say "fix up resolve/$uid" what do you mean? Kapil beat me
> into
> submission in agreeing that exposing resolveuid/$uid in content is
> bearable.

It might be bearable, but I prefer not to expose it and clean it up in
the HTML when the object changes. There are other things that end
developers could want to do when an object is updated, these are just
some examples.

> Audit logging is a very simple extension to contentmirror. Would be
> nice to have a cmirror.auditlog (I have some prototype code but its
> very
> easy). In fact, shouldnt we pick a namespace? cmirror, mirror,
> contentmirror? I'm fine with keeping ore. But kinda sucks ;-( as its
> extra 4 things.

An audit log is good, but it doesn't solve the problem of sending a
notification to the front end framework. But it does make adding in a
cron job much easier.

> You could wire a subscriber to collective.indexing really easily;
> which
> could do some URL stuff.

collective.indexing could be an answer.

For what its with a database trigger and cron job have solved issues
for me right now. But I bet this will crop up in the future.

> NOTE: Kapil really wants to land a contentmirror.async mode before
> 1.0.
> So some of this stuff may not be compatible with that functionality.

async would be very nice, go kapil!
--
Andy McKay
Clearwind Consulting: www.clearwind.ca
Blog: www.agmweb.ca/blog/andy
Twitter: twitter.com/clearwind

[Kapil Thangavelu]

On Wed, Apr 1, 2009 at 3:09 PM, Andy Mckay <an...@clearwind.ca> wrote:

On 1-Apr-09, at 11:15 AM, Alan Runyan wrote:

> You can snap in collective.solr and voila.  You will have SOLR
> updated/remove as you would expect.  Then simply query with solrpy
> library.

Solr is an option for some, but not all. For example spitting Plone
out to cheap web hosts or GAE.

even gae apps have uses for solr.. unless the apps can live without decent search.

afaics gae apps require local data copies for a variety of reasons for featureful/enterprise apps.

 

> I would suggest using content mirror and the CMS events system to
> handle
> the changes.

Not sure I follow you there.

can't say i do either ;-).. but async database table notification is possible with most databases except mysql ( webhosting favorite), of course that depends on what your audience is.

 

> When you say "fix up resolve/$uid" what do you mean?  Kapil beat me
> into
> submission in agreeing that exposing resolveuid/$uid in content is
> bearable.

It might be bearable, but I prefer not to expose it and clean it up in
the HTML when the object changes. There are other things that end
developers could want to do when an object is updated, these are just
some examples.

i found it url management a painful process to manage when doing cmfdeployment and baking static content for deployment, but it did work and has been tested against lots of arbitrary content. if your interested in this approach, i'd recommend grabbing a copy of cmfdeployment, grab the urlresolvers and unit tests, the database becomes the new lookup table for the resolver, maybe call it mirror.staticurls ;-) ?

 

<snip>

 

> You could wire a subscriber to collective.indexing really easily;
> which
> could do some URL stuff.

collective.indexing could be an answer.

For what its with a database trigger and cron job have solved issues
for me right now. But I bet this will crop up in the future.

> NOTE: Kapil really wants to land a contentmirror.async mode before
> 1.0.
> So some of this stuff may not be compatible with that functionality.

async would be very nice, go kapil!

it also gets more complex to install and manage cm for what its worth, a zeo client, and a queue facility ( amqp, sqs, beanstalk, etc). i'm hoping to work on this at the sorrento sprint. tbd, i'm basically on a death march for a release in three weeks. i won't have much time for content mirror development, outside of fixing packaging issues, and 3.2 compatibility till then, fwiw. 

 

cheers,

kapil