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 Pedram Nimreezi <zenstyle@gmail.com>
Full name Pedram Nimreezi <zenstyle@gmail.com>
Date 2007-09-22 15:26:22 PDT
Message I have a lot of experience with memcache... it was definitely not
written to handle
this... but be that as it may I'm pretty sure it can still be done, it
would probably
require the chaining of invalidators along with validators in the
cache aspect...
btw I'm the one that's optimized propel for opcode cache
accelerators... it's just
not a recent version.... summarily I've learned that the bottle neck
is always the
database and not how you connect to it... thats why PDO in my opinion
is overrated
in this context.... you're just not gonna get more performance from the database
no matter how much faster you request or convert the data.... increased speed at
this tier level is completely application level logic... also if you
extract objects
from memcache you still need to include the source files so it's still
not as if you're
pulling data objects hot from the grill... I think SDO can... I know
propel can't... since
it's primarily source based and not extension based... maybe I've
missed the mark..
just throwing my two cents in...

On 9/21/07, Cameron Brunner <cameron.brunner@​gmail.com> wrote:
> No it is not being worked on, there are a lot of issues in relation to
> this that make it quite hard to accomplish in a sane way as when there
> is an update called on a child of a record then you have to invalidate
> both the parent and child's cache data to do it properly. This is no
> small task. It is on the wish-list however honestly I believe we may
> be better to offer a few extra classes to handle this and let the
> programmer handle it themselves. Caching should really be application
> level not ORM level IMO, but that said, if there was a sane way to do
> it on a Propel level, i'd be QUITE interested to see it.
>
> Agavi+Propel+PHPTAL ftw
>
> On 9/21/07, Alexander Kahl <akahl at iconmobile dot com> wrote:
> > Hello Propel developers,
> >
> > I'm using Propel in a framework I've developed for my company and I'm
> > the package maintainer for Propel in Fedora (package status still
> > pending).
> > To seamlessly integrate my framework into our infrastructure, I
> > want/need to use memcache and figured out you're already planning to
> > implement it into Propel (ticket #68). Since we really rely on it I've
> > convinced my employer to implement it myself and contribute back to your
> > project, provided that
> > a) you're not already working on it - at least my generated ChangeLog
> > from your svn repo doesn't say so
> > b) my time estimation to complete the task isn't too high.
> >
> > Before I inspect Propel's internals, I'd like to have ->a) answered and
> > your own time estimation for the task; and, of course, if you'd accept
> > the contribution at all. It would of course be licensed under the
> > LGPLv2, unless you also permit LGPLv3 which I prefer.
> >
> > Regards
> > Alexander Kahl
> >
> > --
> > alexander kahl _ developer
> >
> > iconmobile GmbH _ methfesselstr. 30-36 _ 10965 berlin _ germany
> > phone +49 30 886633 212 _ fax +49 30 886633 150 _ mobile +49 178 8279256
> > akahl at iconmobile dot com _ www.iconmobile.com
> >
> > local court charlottenburg _ hrb 88308
> > managing directors _ thomas fellger | stefan kirschke
> >
> >
>
>
> --
> Cameron Brunner
>
> Want a better web browser?
> http://www.spreadfir​efox.com/?q=affiliat​es&id=182780​&t=1
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>


--
~
Pedram Nimreezi