ViewDefinition Refactoring?

[Martin Alderete]

Hello everybody!

Today I have been playing around with the API.

Does The ViewDefinition class allow us to create a new doc design in
the db? Is this ok or
Am Imissing something?

Does the class ViewDefinition allow us to view all designs inside a
database and manipulate it?
(may be that work should be in Database class inside client.py
module?)

I have tried to monipulate an existent document's design, my code look
like:

def use_view():
url = "http://localhost:5984/"
server = client.Server(url)
document_design_name = "example"
view_name = "test"
#Create a ViewDefinition instance I think that it's a hack...
view = design.ViewDefinition(document_design_name, view_name,
'someViewCode')
#Get a document's design
design_doc = view.get_doc(server["development"])
#Iter over the the views
for view in design_doc["views"]:
print "View name: %s" % view
print "Code: %s" % design_doc["views"][view]["map"]

After the tests I could Create a document design

I found that the class ViewDefinition could be refactored to improve
the features because is not clear to manipulate an existent document's
design, because the class constructor ask us for:

1) A document design name ( it's Ok)
2) View name ( I dont think that it is Ok) IMO this item should be
optional
3) map Function (I dont think that it is Ok) IMO this item should be
optional


Might be the class has to allow us to "add" or "manipulate" in a clear
way!
I'm asking that because I can improve this features!

Cheers,

Martin

[Kxepal]

Hi Martin.

I suppose that better way will be to make some Design document which
will cares about view, shows, updates etc, because views is the one
part of document design. So this class will hold all operations to
manipulate with design. That's will be more useful instead of dancing
around of ViewDefinition - I have another problems to sync a lot of
views of a lot of documents and ViewDefinition couldn't solve this
problem because it's not his work.

[Martin Alderete]

Hi list,

@Kxepal, Yes, I agree with you!
That is the reason I'm desingning  (I'm coding now) this task, create a DesingDocument which hold all the "designs documents" attributes.
Because now the API is not clear in that point, we are using a ViewDefinition to handle a Design Document .
What problem do you have with the sync proccess? In my opinion and design the new class could sync multiples documents in a better way than right now.


Cheers,

Martin

[Kxepal]

On 19 авг, 18:59, Martin Alderete <malder...@gmail.com> wrote:
> Hi list,
>
> @Kxepal, Yes, I agree with you!
> That is the reason I'm desingning  (I'm coding now) this task, create a
> DesingDocument which hold all the "designs documents" attributes.

Great! So I'll to hold on my works in this way. View server is almost
ready to use, so you'll have no problems with lists, shows etc(;

> Because now the API is not clear in that point, we are using a
> ViewDefinition to handle a Design Document .
> What problem do you have with the sync proccess? In my opinion and design
> the new class could sync multiples documents in a better way than right now.

In few words - if I have about 50 document designs with about 100
views in each, I must pass all view fields (5000 items) to sync_many
call. This is madness(: Much more better to define all views somewhere
at once and sync them all at once, while regular documents will have
only bindings to them.

[Martin Alderete]

Hi guys!
How are you?

I haven't written for a while because I have been busy.
I have played around with the ViewDefinition class because I want to improve it, i think that the class is poor in functionallity and should be refactored.
I have tried to replace the ViewDefinition with a DocumentDesign class and his attributes like objects( view objects, reduce objects, etc), the next examples should show the features.

        server = Server("http://localhost:5984")
        db = server["python.tests"]
       
        v_d_f = ValidateFunction("test", "function(doc){...}", language="javascript")
        all = View("all", "function(doc){...}", language="javascript")
        by_name = View("by_name", "function(doc){...}", language="javascript")
        views = (all, by_name)
        #Create the design document
        desing_doc = DesignDocument("_design/tests", validate_doc_fun=v_d_f, views=views)
        #Commit!!
        design_doc.sync(db)
       
        ------------
        server = Server("http://localhost:5984")
        db = server["python.tests"]
        #Get a design document which is already in the db
        design_doc = db.get("_design/tests")

        #Create 2 views
        only_users = View("only_users", "function(doc){...}", reduce_func=None, language="javascript")
        only_admins = View("only_admins", "function(doc){...}", reduce_fun=None, language="javascript")
        new_views = (only_users, only_admins)

        #Add the views to the existing design document.
        design_doc.add_views( new_views )
        #Commit!!
        design_doc.sync(db)

that is all, I hope you could understand my idea and want to hear your comments and suggestions about it.
I could finish the implementation if you think that is needed!

Cheers,

Martin

[Kxepal]

Looks great! While you're haven't finished this feature, will you add
support of issue #105 improvement?

[Dirkjan Ochtman]

On Mon, Sep 13, 2010 at 06:57, Martin Alderete <mald...@gmail.com> wrote:
> I haven't written for a while because I have been busy.
> I have played around with the ViewDefinition class because I want to improve
> it, i think that the class is poor in functionallity and should be
> refactored.

Can you summarize why it's poor in functionality, or why you think it
should be refactored?

Cheers,

Dirkjan

[Kxepal]

I could try to answer:
- it is standalone entity, but it must be a part of document design,
which Martin are currently developing
- it couldn't sync all document views at once, you need to explicitly
pass each document viewfield to it

On 13 сен, 11:22, Dirkjan Ochtman <dirk...@ochtman.nl> wrote:

[Martin Alderete]

Hi guys!!

On 13 сен, 11:22, Dirkjan Ochtman <dirk...@ochtman.nl> wrote:
> Can you summarize why it's poor in functionality, or why you think it
> should be refactored?
 

2010/9/13 Kxepal <kxe...@gmail.com>

I could try to answer:
- it is standalone entity, but it must be a part of document design,
which Martin are currently developing
- it couldn't sync all document views at once, you need to explicitly
pass each document viewfield to it

Yes, that is right, I agree with Kxepal. I think that the current ViewDefinition class only hold a part of couchdb's desing document (only the views), but design documents are specials documentes with powerfull attributes such as views, reduce function, updates functions, show function, etc, so my idea is to try to get together all the attributes in a DesignDocument class.

A DesignDocument class keep the logic and the code more redeable (IMO), because we could sync many design documents.

Martin