Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: [propel-dev] memcache support in Propel

propel
Discussion topic

Hide all messages in topic

All messages in topic

Re: [propel-dev] memcache support in Propel

Reply

Author Pedram Nimreezi <zenstyle at gmail dot com>
Full name Pedram Nimreezi <zenstyle at gmail dot com>
Date 2007-10-05 10:53:38 PDT
Message > You mean the data retrieved simply encapsulated in objects? Say, like if
> you've got a customer table and Propel retrieves all the data for one
> customer, the resulting Customer object instance would be what you call
> a value object..?

Yes, it can also be called a Data Transfer Object... since it's an object, that
holds your data, abstracted as a class that can be transferred to receivers...
(which can be anything that's coded to play nice with it)

>
> oh and if you aren't sure just how EVIL eval() is, go benchmark it,
> anytime you run eval() it forks the php interpreter again over the
> code you eval() and the opcode cache cant do anything nice about
> this... eval() should be renamed evil()...
>

+1 ;), and not just because it's slow... it's also highly unsafe, it's akin to
giving your script access to run anything that can be possibly held in a string
which in (loosely typed) php can be almost anything... eval is a bad ju ju...

if you're not afraid of some hairy c code.. look up Vulcan Logic SRM... that has
a very unique way of keeping objects live, and active in memory...
written by the
same guy that makes xdebug (talk about credentials)... but at last
look it had bugs.
might give you some unique insight, in fact since some of the code is
mirrored...
(in that they're both a separate daemon with memory persistency) maybe memcache
extensions could be made to facilitate this... I may have to
investigate this further...

Oh btw, the AMF extension is stupid fast... it uses some linked list
buffering strategies
which may shed some more optimization enlightenment...



> On 10/5/07, Alexander Kahl <akahl at iconmobile dot com> wrote:
> > Hi Pedram :)
> >
> > On Thu, 2007-10-04 at 12:16 -0400, Pedram Nimreezi wrote:
> > > > Am I getting something
> > > > totally wrong here?
> > >
> > > Only slightly
> > Then I'll try to get the whole idea.


--
~
Pedram Nimreezi
Internet Developer / Frameworkologist
mc at majorcomputing dot com | pedram at 5g dot com
--
No man is a complete failure until he begins disliking men who succeed

Re: [propel-dev] memcache support in Propel

Reply

Author Alexander Kahl <akahl at iconmobile dot com>
Full name Alexander Kahl <akahl at iconmobile dot com>
Date 2007-10-05 05:50:04 PDT
Message On Fri, 2007-10-05 at 22:26 +1000, Cameron Brunner wrote:
> Correct me if im wrong, your using propel 1.2 combined with symfony
> and your trying to optimize for speed? *sigh*
No, you are as wrong as you can be ;) I've considered using symfony
months ago and found so many things I dislike that much I decided to
create my own specialized framework, or better, web engine in this case.
Unfortunately I cannot make my engine free software but convinced my
employer to let me contribute back to the community.

> propel 1.3 has already replaced creole with pdo and there are FAR
> lighter weight solutions than symfony for a framework
Yes, symfony is not only one heavy beast of a framework but I felt like being kept in cage with it. Symfony somehow forces you to always do things the symfony way.

> oh and if you aren't sure just how EVIL eval() is, go benchmark it,
> anytime you run eval() it forks the php interpreter again over the
> code you eval() and the opcode cache cant do anything nice about
> this... eval() should be renamed evil()...
Right now I'm not doing something like that, fortunately. But thanks for
the info, so I don't have to benchmark that myself anymore.

--
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
Attachments

Re: [propel-dev] memcache support in Propel

Reply

Author Cameron Brunner <cameron dot brunner at gmail dot com>
Full name Cameron Brunner <cameron dot brunner at gmail dot com>
Date 2007-10-05 05:26:37 PDT
Message Correct me if im wrong, your using propel 1.2 combined with symfony
and your trying to optimize for speed? *sigh*

propel 1.3 has already replaced creole with pdo and there are FAR
lighter weight solutions than symfony for a framework

oh and if you aren't sure just how EVIL eval() is, go benchmark it,
anytime you run eval() it forks the php interpreter again over the
code you eval() and the opcode cache cant do anything nice about
this... eval() should be renamed evil()...

On 10/5/07, Alexander Kahl <akahl at iconmobile dot com> wrote:
> Hi Pedram :)
>
> On Thu, 2007-10-04 at 12:16 -0400, Pedram Nimreezi wrote:
> > > Am I getting something
> > > totally wrong here?
> >
> > Only slightly
> Then I'll try to get the whole idea.
>
> > > I want to cache persistent data that is retrieved
> > > and modified via Propel.
>
> > Ahh... that's the problem to attack... I agree the logic
> > for memcache should be in Propel... moving towards
> > that being implemented can we agree that the first step
> > is checking to see the memcache extension is loaded?
> Yes of course, the memcache support should be optional.
>
> > If not using like... a CreoleSession? (i wrote that if you need it btw)
> You've wrote it already? Where can I find it?
> But it's planned to replace Creole support by PHP PDO right? Read it
> somewhere on the website.
>
> > if the extension 'memcache' IS loaded... then look for memcache
> > server config in the propel.ini, it should be an array because you
> > can use memcache in a distributed fashion.
> I think propel.ini configuration support should be provided as well as
> generic methods. Like, right now I'm initializing Propel with
> configuration parsed from YAML files and at least that should also be
> possible for the optional memcache support.
>
> > And in the code generator
> > insert the requisite cache validation, invalidation, max buffers, etc...
> Exactly
>
> > > What if you'd even hold the compiled Propel code in cache?
> > How would you execute it? a big eval() ? that kinda steps forward and
> > again backwards.
> You think we can get nothing out of that?
>
> > But that's moving towards an extension based implementation and that's hot... ;)
> I'd always favor extensions wherever feasible and useful at all. Maybe
> the cache support should even be abstracted and memcache support
> encapsulated that way so it'll even be more extensible and modular.
>
> > > > > You mean requesting memcache data still requires to include Propel's
> > > > > generated files to get the actual related request..?
> > > > >
> > > > right.. unless of course you used separate data transfer objects (value objects)
> > > > to represent that data....
> > > Right now this concept doesn't sound familiar to me. Can you tell me where it is used?
> > >
> >
> > It's used whenever you want to abstract data as an object, propel does
> > it transparently
> > or you can have a couple of your own... externally. Passing value
> > objects that represent
> > actual meanings instead of primitive datatypes to explain (self
> > document) that meaning.
> You mean the data retrieved simply encapsulated in objects? Say, like if
> you've got a customer table and Propel retrieves all the data for one
> customer, the resulting Customer object instance would be what you call
> a value object..?
>
> --
> 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

Re: [propel-dev] memcache support in Propel

Reply

Author Alexander Kahl <akahl at iconmobile dot com>
Full name Alexander Kahl <akahl at iconmobile dot com>
Date 2007-10-05 05:03:59 PDT
Message Hi Pedram :)

On Thu, 2007-10-04 at 12:16 -0400, Pedram Nimreezi wrote:
> > Am I getting something
> > totally wrong here?
>
> Only slightly
Then I'll try to get the whole idea.

> > I want to cache persistent data that is retrieved
> > and modified via Propel.

> Ahh... that's the problem to attack... I agree the logic
> for memcache should be in Propel... moving towards
> that being implemented can we agree that the first step
> is checking to see the memcache extension is loaded?
Yes of course, the memcache support should be optional.

> If not using like... a CreoleSession? (i wrote that if you need it btw)
You've wrote it already? Where can I find it?
But it's planned to replace Creole support by PHP PDO right? Read it
somewhere on the website.

> if the extension 'memcache' IS loaded... then look for memcache
> server config in the propel.ini, it should be an array because you
> can use memcache in a distributed fashion.
I think propel.ini configuration support should be provided as well as
generic methods. Like, right now I'm initializing Propel with
configuration parsed from YAML files and at least that should also be
possible for the optional memcache support.

> And in the code generator
> insert the requisite cache validation, invalidation, max buffers, etc...
Exactly

> > What if you'd even hold the compiled Propel code in cache?
> How would you execute it? a big eval() ? that kinda steps forward and
> again backwards.
You think we can get nothing out of that?

> But that's moving towards an extension based implementation and that's hot... ;)
I'd always favor extensions wherever feasible and useful at all. Maybe
the cache support should even be abstracted and memcache support
encapsulated that way so it'll even be more extensible and modular.

> > > > You mean requesting memcache data still requires to include Propel's
> > > > generated files to get the actual related request..?
> > > >
> > > right.. unless of course you used separate data transfer objects (value objects)
> > > to represent that data....
> > Right now this concept doesn't sound familiar to me. Can you tell me where it is used?
> >
>
> It's used whenever you want to abstract data as an object, propel does
> it transparently
> or you can have a couple of your own... externally. Passing value
> objects that represent
> actual meanings instead of primitive datatypes to explain (self
> document) that meaning.
You mean the data retrieved simply encapsulated in objects? Say, like if
you've got a customer table and Propel retrieves all the data for one
customer, the resulting Customer object instance would be what you call
a value object..?

--
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
Attachments

Re: [propel-dev] memcache support in Propel

Reply

Author Pedram Nimreezi <zenstyle at gmail dot com>
Full name Pedram Nimreezi <zenstyle at gmail dot com>
Date 2007-10-04 09:16:28 PDT
Message hi... ;)

On 10/2/07, Alexander Kahl <akahl at iconmobile dot com> wrote:
> On Tue, 2007-09-25 at 01:52 -0400, Pedram Nimreezi wrote:
> > > On Sat, 2007-09-22 at 18:26 -0400, Pedram Nimreezi wrote:
> > > > I have a lot of experience with memcache... it was definitely not
> > > > written to handle this...
> > > To handle what exactly? According to its docs, It was written primarily
> > > for caching frequent DBMS requests and load-balancing the results
> > > between several involved memcache servers.
> > > Do you mean it wasn't written to handle every single DBMS request
> > > possible?
> >
> > yes.. to start.. it's a completely abstract container..
> > designed to hold and retrieve data... if it's session data that's not
> > it's concern.
> Does Propel hold and/or retrieve session data?

Yes, any data...


> Am I getting something
> totally wrong here?

Only slightly

> I want to cache persistent data that is retrieved
> and modified via Propel.
>


Ahh... that's the problem to attack... I agree the logic
for memcache should be in Propel... moving towards
that being implemented can we agree that the first step
is checking to see the memcache extension is loaded?

If not using like... a CreoleSession? (i wrote that if you need it btw)
if the extension 'memcache' IS loaded... then look for memcache
server config in the propel.ini, it should be an array because you
can use memcache in a distributed fashion. And in the code generator
insert the requisite cache validation, invalidation, max buffers, etc...


> > > > 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...
> What if you'd even hold the compiled Propel code in cache?


How would you execute it? a big eval() ? that kinda steps forward and
again backwards.
But that's moving towards an extension based implementation and that's hot... ;)

>
> > > You mean requesting memcache data still requires to include Propel's
> > > generated files to get the actual related request..?
> > >
> > right.. unless of course you used separate data transfer objects (value objects)
> > to represent that data....
> Right now this concept doesn't sound familiar to me. Can you tell me where it is used?
>

It's used whenever you want to abstract data as an object, propel does
it transparently
or you can have a couple of your own... externally. Passing value
objects that represent
actual meanings instead of primitive datatypes to explain (self
document) that meaning.

> --
> 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
>
>


--
~
Pedram Nimreezi
Internet Developer / Frameworkologist
mc at majorcomputing dot com | pedram at 5g dot com
--
No man is a complete failure until he begins disliking men who succeed

Re: [propel-dev] memcache support in Propel

Reply

Author Alexander Kahl <akahl at iconmobile dot com>
Full name Alexander Kahl <akahl at iconmobile dot com>
Date 2007-10-02 09:13:00 PDT
Message On Tue, 2007-09-25 at 01:52 -0400, Pedram Nimreezi wrote:
> > On Sat, 2007-09-22 at 18:26 -0400, Pedram Nimreezi wrote:
> > > I have a lot of experience with memcache... it was definitely not
> > > written to handle this...
> > To handle what exactly? According to its docs, It was written primarily
> > for caching frequent DBMS requests and load-balancing the results
> > between several involved memcache servers.
> > Do you mean it wasn't written to handle every single DBMS request
> > possible?
>
> yes.. to start.. it's a completely abstract container..
> designed to hold and retrieve data... if it's session data that's not
> it's concern.
Does Propel hold and/or retrieve session data? Am I getting something
totally wrong here? I want to cache persistent data that is retrieved
and modified via Propel.

> > > 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...
What if you'd even hold the compiled Propel code in cache?

> > You mean requesting memcache data still requires to include Propel's
> > generated files to get the actual related request..?
> >
> right.. unless of course you used separate data transfer objects (value objects)
> to represent that data....
Right now this concept doesn't sound familiar to me. Can you tell me where it is used?

--
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
Attachments

Re: [propel-dev] memcache support in Propel

Reply

Author Alexander Kahl <akahl at iconmobile dot com>
Full name Alexander Kahl <akahl at iconmobile dot com>
Date 2007-10-02 09:07:26 PDT
Message On Tue, 2007-09-25 at 15:25 +1000, Cameron Brunner wrote:
> memcache knows nothing of relationships, update a parent, the children
> need to be updated too, there in itself lies a HUGE issue. David has
> come up with a concept on how to handle this somewhat but on a site
> with a lot of updates, its completely useless to add a caching layer
> in this respect.
Of course memcache is only the backend for the caching discussed. I'd
really appreciate if you provide a link to the concept you've mentioned.

Let's assume we'd just cache all selects and invalidate the whole cache
upon updates, wouldn't we still get a slight performance boost? At this
point the caching could be improved step by step if possible.

> Anyway, my 2c, propel is the wrong place to be doing this for the most
> part, i would seriously reconsider the level you are trying to
> implement memcache at at this point in time. You could always create a
> wrapper to BlahPeer::doSelect that had an optional cacheTimeout
> variable that let you set a static timeout for the cache but... i'm
> not a fan of time based caches, if they aren't intelligent there is
> little point a lot of the time. Anyway, good luck either way.
That means you'd rather place an additional layer between Propel and
Creole/PDO than coupling the caching with Propel directly? Wouldn't that
mean to duplicate Propel's functionality at some places like
parent-children relationship mappings? So in how far would that be
better?

--
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
Attachments

Re: [propel-dev] memcache support in Propel

Reply

Author Pedram Nimreezi <zenstyle at gmail dot com>
Full name Pedram Nimreezi <zenstyle at gmail dot com>
Date 2007-09-24 22:52:39 PDT
Message first of all I'm agreeing with Cameron...

On 9/24/07, Alexander Kahl <akahl at iconmobile dot com> wrote:
> Hi Pedram
>
> On Sat, 2007-09-22 at 18:26 -0400, Pedram Nimreezi wrote:
> > I have a lot of experience with memcache... it was definitely not
> > written to handle this...
> To handle what exactly? According to its docs, It was written primarily
> for caching frequent DBMS requests and load-balancing the results
> between several involved memcache servers.
> Do you mean it wasn't written to handle every single DBMS request
> possible?

yes.. to start.. it's a completely abstract container..
designed to hold and retrieve data... if it's session data that's not
it's concern.

>
> > 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....
> Is this related to the actual discussion? I don't get the point of how
> the DBMS abstraction layer is involved here, sorry.
>
talking optimization... it has many areas...sorry

> > 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...
> You mean requesting memcache data still requires to include Propel's
> generated files to get the actual related request..?
>
right.. unless of course you used separate data transfer objects (value objects)
to represent that data....

>
> --
> 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
>
>


--
~
Pedram

Re: [propel-dev] memcache support in Propel

Reply

Author Cameron Brunner <cameron dot brunner at gmail dot com>
Full name Cameron Brunner <cameron dot brunner at gmail dot com>
Date 2007-09-24 22:25:07 PDT
Message memcache knows nothing of relationships, update a parent, the children
need to be updated too, there in itself lies a HUGE issue. David has
come up with a concept on how to handle this somewhat but on a site
with a lot of updates, its completely useless to add a caching layer
in this respect.

Anyway, my 2c, propel is the wrong place to be doing this for the most
part, i would seriously reconsider the level you are trying to
implement memcache at at this point in time. You could always create a
wrapper to BlahPeer::doSelect that had an optional cacheTimeout
variable that let you set a static timeout for the cache but... i'm
not a fan of time based caches, if they aren't intelligent there is
little point a lot of the time. Anyway, good luck either way.

On 9/24/07, Alexander Kahl <akahl at iconmobile dot com> wrote:
> Hi Pedram
>
> On Sat, 2007-09-22 at 18:26 -0400, Pedram Nimreezi wrote:
> > I have a lot of experience with memcache... it was definitely not
> > written to handle this...
> To handle what exactly? According to its docs, It was written primarily
> for caching frequent DBMS requests and load-balancing the results
> between several involved memcache servers.
> Do you mean it wasn't written to handle every single DBMS request
> possible?
>
> > 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....
> Is this related to the actual discussion? I don't get the point of how
> the DBMS abstraction layer is involved here, sorry.
>
> > 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...
> You mean requesting memcache data still requires to include Propel's
> generated files to get the actual related request..?
>
>
> --
> 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

Re: [propel-dev] memcache support in Propel

Reply

Author Alexander Kahl <akahl at iconmobile dot com>
Full name Alexander Kahl <akahl at iconmobile dot com>
Date 2007-09-24 02:31:12 PDT
Message Hi Pedram

On Sat, 2007-09-22 at 18:26 -0400, Pedram Nimreezi wrote:
> I have a lot of experience with memcache... it was definitely not
> written to handle this...
To handle what exactly? According to its docs, It was written primarily
for caching frequent DBMS requests and load-balancing the results
between several involved memcache servers.
Do you mean it wasn't written to handle every single DBMS request
possible?

> 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....
Is this related to the actual discussion? I don't get the point of how
the DBMS abstraction layer is involved here, sorry.

> 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...
You mean requesting memcache data still requires to include Propel's
generated files to get the actual related request..?


--
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
Attachments

Re: [propel-dev] memcache support in Propel

Reply

Author Pedram Nimreezi <zenstyle at gmail dot com>
Full name Pedram Nimreezi <zenstyle at gmail dot 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

Re: [propel-dev] memcache support in Propel

Reply

Author Cameron Brunner <cameron dot brunner at gmail dot com>
Full name Cameron Brunner <cameron dot brunner at gmail dot com>
Date 2007-09-21 17:04:30 PDT
Message 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

memcache support in Propel

Reply

Author Alexander Kahl <akahl at iconmobile dot com>
Full name Alexander Kahl <akahl at iconmobile dot com>
Date 2007-09-21 03:44:35 PDT
Message 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
Attachments
Messages per page: