Login | Register
My pages Projects Community openCollabNet

propel
Reply to message

* = Required fields
* Subject
* Body
Attachments
Send reply to
Topic
Author (directly in email)
Please type the letters in the image above.

Original message

Author Ron Rademaker <r.rademaker@virtualbuilding.nl>
Full name Ron Rademaker <r.rademaker@virtualbuilding.nl>
Date 2008-05-05 07:16:33 PDT
Message Hi all,

I picked up on the mail below again (which I've send to the list last
November) last week and today. I actually got the first handler (which
creates backups when changing db records) working in a very limited
test. I don't think it would be a good idea to commit this to 1.3
because I expect this first version to still be quite buggy (and getting
1.3 into RC would be nice) . However, from the looks of it trunk is
pretty old right now (and the event handler thing requires the commit I
did this morning) and nobody probably uses trunk so it wouldn't get
tested anyway. Where should I commit this stuff?

Ron

Ron Rademaker wrote:
> Hi all,
>
> Last week I told you about my idea to create a backup function in
> propel based on sql triggers. I've been working on this a bit this
> week only to find out sql triggers and procedures have some very
> annoying properties. This would result in having to redefine all
> triggers whenever you change your schema, and often no errors if you
> forget to do this (and I *know* I would something forget it and I
> would be *very* surprised if the other developers here wouldn't). I
> don't think this is a good idea so I've come up with a different, much
> more flexible, database independent solution. The only drawback I see
> is that performance would be better if the backup functionality was
> implemented in sql.
>
> The basic idea is that you can add event to tables and columns (and
> databases, though I haven't though of a useful example for that yet).
> An example schema (I think the first event is obvious, I'll explain
> the second later) could be:
>
> <table name='foo'>
> <column name='id' primaryKey='true' type='INTEGER'
> autoIncrement='true'/>
> <column name='date' type='TIMESTAMP'/>
> <column name='bar' type='VARCHAR'/>
> <event occasion='onChange'> <!-- this is now defined on the table,
> but could also be defined on the bar column -->
> <handler name='setcolumn'>
> <parameter name='column' value='date'/>
> <parameter name='value' type='phpfunction'>
> <function name='date'>
> <parameter value='"now"'/>
> </function>
> </parameter>
> </handler>
> </event>
> <event occasion='onCreate'>
> <handler name='saver' function='registerSave'/>
> </event>
> <event occasion='onSave'>
> <handler name='saver' function='triggerSave'/>
> </event>
> </table>
> <table name='bar'>
> <column name='id' primaryKey='true' type='INTEGER'
> autoIncrement='true'/>
> <column name='bar' type='VARCHAR'/>
> <event occasion='onCreate'>
> <handler name='saver' function='registerSave'/>
> </event>
> <event occasion='onSave'>
> <handler name='saver' function='triggerSave'/>
> </event>
> </table>
>
> Both table foo and bar have the saver handler for the onCreate and
> onSave event. I intent to implement the event / handler structure
> using the observer pattern, Propel objects being Observables and event
> handlers being Observers. The saver handler (observer) would be an
> example where the onCreate event registers the propel object with the
> handler and the onSave triggers save on all registered objects. This
> way you can save multiple objects with a single save() call,
> potentially this means you could tweak things so that you would add or
> update many objects in a single sql query.
> I know many of the things this will make possible are already possible
> by overriding functions in the propel classes. I do believe however,
> that this mechanism would prove to be very flexible and easier to
> maintain than implementations in propel classes (I still have a whole
> lot of classes where I need to change save(PDO $con = nul) to
> save(PropelPDO $con = null)).
> I'll be starting to build this shortly, anyone having suggestions,
> improvements, seeing upfront bottlenecks, just let me know and if I
> think it makes sense I'll try to do something useful with it ;)
>
> Ron
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>