hey ravi,
sorry for the delay. i really need human readable paths so the using ids
instead of names does not really work for my case and keeping all parents is
also part of the app design so keeping only the direct parent does not work
either.
thank you for your thoughts anyway!!
andreas
On Jul 2, 2011, at 3:49 PM, Ravi Sharma wrote:
> one last idea.....make your http paths with keys
> instead of having
> /root/p1/p2/p3
> have something like this
> /1000/1001/1002/1003 (assuming root's id is 1000 and so on)
>
> Now you can query a folder using last node in this path 1003..forget about
> who is his parent as 1003 can have only one parent, so even later you moved
> into some other folder 1000/1001/1002/1004/1006/1007/1003, same query will
> run and return same data with same amount of get (1 get)
>
> Regardning previous suggestion:
>
> I still wont keep all parents..i will just keep one parent above me.... it
> will make editing of my tree easier
>
> Now its upto you and your requiremtns and design..that how you will settle
> between these constraint
> 1) Renaming/Copying/editing millions of file/directory problem
> 2) Traversing n levels for each request.....
>
> you are creating tree structure dont make each node know on which path it is
> to make traversal faster...... if you do so editing of tree will be worst....
>
> and now i am out of ideas ..:)
>
> Happy thinking..coding
> Ravi.
>
>
> On Sat, Jul 2, 2011 at 2:20 PM, andreas schmid <a.schmi...@gmail.com> wrote:
> hi ravi,
>
> i was not thinking to make the folder know about its children. files and
> folders have a StringListProperty where i store all keys of the folders it
> belongs to.
>
> your approach is exactly what i wanted to avoid. i think its not the right
> way to do this because the longer the path the longer the query and lets say
> im at level 10, ill need to do 10 get() operations.
>
>
> On Jul 2, 2011, at 2:55 PM, Ravi Sharma wrote:
>
>> One Suggestion
>> Instead of making a folder know his all child folder and files..may be try
>> other way round by letting every folder/file know its parent... also save
>> depth of folder and files......
>> e.g.
>> Class File{
>> Key id,
>> String anme;
>> Key parentId,
>> int depth;
>> String type;//folder or file
>> }
>>
>> and for path point of view i think you will show your folders like
>> yoursite.com/root/parent1/parent2
>> then on server for this request
>>
>> first search a folder entry where name=root and depth =1
>> you will get only one record at this level you can not have more then one
>> root folder
>>
>> then search for folder entry where name=parent1 and depth =2 and parent
>> id=<id of entity found above>
>> you will find only one entry at this depth with this parent....
>>
>> and same search for parent2
>>
>>
>> this way whenever you will have long path you will do few more queries...
>> but renaming wont be a problem...... and copying content from one folder to
>> another will be lot easier....
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Jul 2, 2011 at 11:25 AM, andreas schmid <a.schmi...@gmail.com> wrote:
>> hi,
>>
>> I'm trying to build a filesystem like folder tree on appengine python but
>> I'm not sure about the architecture of the app.
>>
>> lets say i have folders and images. folders can contain other folders and
>> images. building the relationship is not the problem
>> because every entity will have a StringListProperty with all the keys to the
>> folders it belongs.
>>
>> the folders will have a path which lets me know which folder contents to
>> show on the site. like in a filesystem i would like to be
>> able to rename a folder. if i rename a folder all child folders of that
>> folder will have to change path too.
>>
>> is it possible to know a folders path based on its ancestors without writing
>> the path into the folder entity and of course without fetching all folders
>> in the path?
>>
>> i would like to avoid this because if i change a folders name on the root
>> level i will need to do an update operation on all subfolders to change
>> this path and if there will be for example 500+ subfolders in the tree it
>> wont be an easy and quick operation.
>>
>> would love to hear your suggestions.
>>
>> thank you
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google App Engine" group.
>> To post to this group, send email to google-appengine@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-appengine+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-appengine?hl=en.
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google App Engine" group.
>> To post to this group, send email to google-appengine@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-appengine+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-appengine?hl=en.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.
