5000 records is a lot of data, so I'm not surprised its slow since it pulls directly from the database. We are working on moving the grid data into the internal search index so it can become much much faster.

Ok, that sounds like a good idea. I hope we get to the point where 5000 records may not be thought of as a lot of data one day. Thanks for the update and all the effort. Your doing a great job.

is there an issue in the issue tracker already that you know of or I can go and make one

Hi 

Could you just exapnd on what you mean when you say 'enable list view for a repository'

Are you using the listview to display something from a sufrace controller or similar? Do you have an example? I cant find anything just now.

Thanks

What I mean by a Repository is a Node in the tree that contains child nodes designed for a specific purpose.

For Example, I create a News folder and place News Items in that folder. I was referring to the News folder as a repository of News Items :)

Just to be clear also, I am talking about the new option on a Node that allows you to view the childnodes as a list rather than a node in the tree. To turn this on, you check the box on the Generic Properties Tab called "Enable List View".

Hi

Thanks for the feedback.

I know about the list items etc but i thought i was missing something where you could load items into this list from an alternative source other than child content items.

I do actually want to do something like this where I have some items that are persisted to a DB table rather than the umbraco content database - stuff that i dont want cluttering up the tree but related to the node itself.

Just wanted to make sure i wasnt missing a new feature in v7 as its still quite new to me.

As an aside do you know of any packages/techniques to do the above? Guess i should create a new thread rather than clutter this one up - even though its related.

Cheers,

Damian

I noticed the same perf issues (3000 child nodes all of the same type).

Per - I developed the v6 component that does similar stuff:
http://our.umbraco.org/projects/backoffice-extensions/rbccontainerdocumenttype 

I havent looked into the backoffice code for v7 (or any AngularJS stuff at all) to see how it is "hitting the database" but my implementation can handle a lot of nodes - I've tested on 15,000 child nodes and get response times in the 1-2 second range so maybe I can help.  I dont use PetaPoco but a direct SQL call as shown below.

The main thing that my implementation doesnt support is that you show child nodes of different types in the same list and I dont provide that - I think a UNION ALL would fix that though.  I am also missing, publish, delete, etc but adding that to my code would not impact "listing" performance.

Shoot me an email if you need to discuss in more detail.

Regards,
Matt 

SQL I'm using - change 'resource' in sql below  on line 14 to whatever doc alias you want to grab as your child nodes.  Note that I also left in some commented out sql that shows how I also grab custom properties you might have on that doc type in case you wanted to show them in the list instead of your nodeName:

select 
    umbracoNode.Id
    --,data2.dataNVarchar as 'articleTitle'
    --,data1.dataDate as 'articleDate'
    ,cmsDocument.updateDate
    ,cmsDocument.[text]
    ,CASE WHEN cmsContentXml.nodeId IS NULL THEN 0 ELSE 1 END as 'Published' --published at all or not?
    ,CASE WHEN published = 1 THEN 0 ELSE 1 END as 'Saved' --latest version published?
    --,cmsDocument.*
from umbracoNode
    inner join cmsContent on umbracoNode.Id = cmsContent.nodeId
    inner join cmsDocument on cmsDocument.nodeId = umbracoNode.id
    left outer join cmsContentXml on cmsContentXml.nodeId = cmsDocument.nodeId
    inner join cmsContentType on cmsContent.contentType = cmsContentType.nodeId and cmsContentType.alias = 'resource'
    --inner join cmsPropertyType ptype1 on ptype1.contentTypeId = cmsContentType.nodeId and ptype1.Alias = 'articleDate'
    --inner join cmsPropertyData data1 on data1.contentNodeId = umbracoNode.Id and data1.propertytypeid = ptype1.id and data1.versionId = cmsDocument.versionId
    --inner join cmsPropertyType ptype2 on ptype2.contentTypeId = cmsContentType.nodeId and ptype2.Alias = 'articleTitle'
    --inner join cmsPropertyData data2 on data2.contentNodeId = umbracoNode.Id and data2.propertytypeid = ptype2.id and data2.versionId = cmsDocument.versionId
    where trashed = 0
    and cmsDocument.newest = 1
    order by cmsDocument.updateDate desc

Should also say that my original (non released) version of my package did use Examine but I found for bulk operations (part of an internal version) did not work correctly - essentially the Internal Index could not keep up and index things quick enough, so you'd perform an action on items in the list but the slightly outdated Lucene index would still show the old content.

Regards,
Matt 

is working on a reply...