Structures_DataGrid DataObject DataSource

Hi !
I just checked the CVS (via web interface), seems work is in
progress  
for the new release of SDG, nice !

I just want to tell you about something I was thinking of in
the  
DataObject DataSource file. Maybe it's still too early to
talk about  
such details. Anyway I think this might still be up to date
later.

I experience some performance hits using dataobjects as a
datasource  
for a SDG, if I turn formbuilder_integration to true. This
is due I  
think to the many database access to get all the linked
records, I  
think it could be worth optimising

Ideally would be to make joins so that all the necessary
information  
is fetched from only one db query. But it might be a bit
complicated  
and unstable (IMHO)

What I did is store the linked records in an array for
caching  
purpose. It's quite efficient with recurrent links (like
country,  
categories etc...). What do you think ? it could be
activated in the  
options passed to the bind() method.

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Hi Arnaud,

arnaud sellenet bodin wrote:
> Hi !
> I just checked the CVS (via web interface), seems work
is in progress 
> for the new release of SDG, nice !

Thanks, lots of work indeed. SDG's been through a quite
long refactoring.

> I just want to tell you about something I was thinking
of in the 
> DataObject DataSource file. Maybe it's still too early
to talk about 
> such details. Anyway I think this might still be up to
date later.

The refactoring mainly concerns the renderer layer (see bug
#5859). You are
talking about the datasource layer which is the other half
of SDG. So yeah, it's
a bit early, cause the current goal is to release the new
renderer design.

> I experience some performance hits using dataobjects as
a datasource 
> for a SDG, if I turn formbuilder_integration to true.
This is due I 
> think to the many database access to get all the linked
records, I 
> think it could be worth optimising

That's heavy indeed. Unfortunately, I never used the
formbuilder_integration
option myself. I already integrated SDG with FB in the past,
but that was before
this option.

> Ideally would be to make joins so that all the
necessary information  is
> fetched from only one db query. But it might be a bit
complicated  and
> unstable (IMHO)

It sounds complicated, but it certainly is the best in
regard to the relational
database paradigm.

> What I did is store the linked records in an array for
caching  purpose.
> It's quite efficient with recurrent links (like
country,  categories
> etc...). What do you think ? it could be activated in
the  options
> passed to the bind() method.

I think that it's good as well, and certainly easier to
optimize than complex joins.

IMO if the dataobject driver was modular enough you should
be able to do what
you need by subclassing it. Everything that's related to
fetching links should
go into methods that one can overload in order to provide
his/her own
link-fetching routines.

This way you may be able to use either joins or arrays in
your customized
driver. You may be able to precisely optimize the
link-fetching routines for
your specific needs.

What do you think about this ?

--
  og

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On 3/22/06, Olivier Guilyardi <ojaimlnerim.net> wrote:
> Hi Arnaud,
>
> arnaud sellenet bodin wrote:
> > Hi !
> > I just checked the CVS (via web interface), seems
work is in progress
> > for the new release of SDG, nice !
>
> Thanks, lots of work indeed. SDG's been through a
quite long refactoring.
>
> > I just want to tell you about something I was
thinking of in the
> > DataObject DataSource file. Maybe it's still too
early to talk about
> > such details. Anyway I think this might still be
up to date later.
>
> The refactoring mainly concerns the renderer layer (see
bug #5859). You are
> talking about the datasource layer which is the other
half of SDG. So yeah, it's
> a bit early, cause the current goal is to release the
new renderer design.
>
> > I experience some performance hits using
dataobjects as a datasource
> > for a SDG, if I turn formbuilder_integration to
true. This is due I
> > think to the many database access to get all the
linked records, I
> > think it could be worth optimising
>
> That's heavy indeed. Unfortunately, I never used the
formbuilder_integration
> option myself. I already integrated SDG with FB in the
past, but that was before
> this option.
>
> > Ideally would be to make joins so that all the
necessary information  is
> > fetched from only one db query. But it might be a
bit complicated  and
> > unstable (IMHO)
>
> It sounds complicated, but it certainly is the best in
regard to the relational
> database paradigm.
>
> > What I did is store the linked records in an array
for caching  purpose.
> > It's quite efficient with recurrent links (like
country,  categories
> > etc...). What do you think ? it could be activated
in the  options
> > passed to the bind() method.
>
> I think that it's good as well, and certainly easier
to optimize than complex joins.
>
> IMO if the dataobject driver was modular enough you
should be able to do what
> you need by subclassing it. Everything that's related
to fetching links should
> go into methods that one can overload in order to
provide his/her own
> link-fetching routines.
>
> This way you may be able to use either joins or arrays
in your customized
> driver. You may be able to precisely optimize the
link-fetching routines for
> your specific needs.
>
> What do you think about this ?
>

Right now the DataObject driver is using FormBuilder to pull
these
names and it does indeed use one query per record, mostly
because it
was what worked and what I could get working right off the
bat. It
should be possibel to do this using a join, but with the way
that this
currently works in FormBuilder this would still be one query
per row.

It should also be possible to rewrite the code in the
DataObject
driver to use joins instead of pulling from FormBuilder, but
it's
going to take a recursive algorithm and some testing to make
it work
well.

--
Justin Patrin

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php