DAL alternatives

[António Ramos]

Why is there very litle interest in the DAL github repo (very litle forks and stars) ?

Are people using better alternatives or does it suffer from some lack of publicity or even worse, people dont like it because they dont like web2py either.

Regards

António

[Richard Vézina]

Do you mean pyDAL?

If so, you have to consider that it is very young and may still seems to be web2py related which may make poeple think that they can't use it without web2py...

I use to refer many StackOverflow asker to pyDAL as a way to solve their issue, I guess word of mouth is not in use enough.

Anyway pyDAL is amanzing piece of software and I don't mind if it stays a really good kept secret...

:)

Richard

--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups "web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[António Ramos]

I agree with you except for the "kept secret" because it keeps away people that could help make it even better.

and yes, i meant pyDAL

[António Ramos]

pyDAL is the choice.

But if i use it outside web2py i need an alternative http server/rest endpoint and something to auth clients.

What do you suggest to add to pyDAL ?

Regards

António

[Bernard Letourmy]

Hi Ramos,
What's your project ?
Because if you do some console, desktop or Python notebook doc.
standalone pydal is there.
But if you're looking at developing a web app or rest api
Web2py Is quite good at it and quite well integrated with pydal  ;)

Or what  inconvenience do you see with web2py for this project?

Maybe I misunderstood your question... do you want to cut an other module out of web2py to end up with a new lighter  modular framework alternative ?

otherwise all well known alternative python web frameworks are there to try pydal with.

Guess in Django you could build custom model on top of pydal, ORM tight integration, documentation, external app and default contrib modules will not help somebody who don't know very well the framework already.

I've no experience with flask, but it would look like an easier candidate as it is more independent from a db backend. 

Thanks
Bernard

[António Ramos]

my inconvenients:

1 - Bootstrap, i need layout.html but dont want bootstrap. How do i get rid of bootstrap or change it to semantic ?

     Bootstrap should not be a constraint but just an add-on. 

2 - web2py custom forms and tables. Are nice tools but if they dont do what you want you will have a big mess of code/style to customize it.

    I prefer doing it frontend side with angular/Vuejs/etc. Gives me more tools for my personal CV and the code looks better, however it lacks proper data binding with web2py and i end up having 2 separate apps, one frontend and one backend via REST. I dont like it.

Regards

2015-10-28 11:28 GMT+00:00 Bernard Letourmy <bernard....@gmail.com>:

Hi Ramos,
What's your project ?
Because if you do some console, desktop or Python notebook doc.
standalone pydal is there.
But if you're looking at developing a web app or rest api
Web2py Is quite good at it and quite well integrated with pydal  ;)

Or what  inconvenience do you see with web2py for this project?

Thanks
Bernard

[Marin Pranjić]

Hey!

Bootstrap was never a constraint, I am removing it from every single project and adding foundation/semantic/custom - I can't stand it.

I am also manually writing forms (everything in between of form.custom.begin and form.custom.end) while using the power of SQLFORMs on backend.

What do you mean by lacks proper data binding? You mean between client and server?

If you're going with pyDAL, you are using python on backend. So, what are your stack goals that can't be achieved with web2py?

If you can explain your issues a bit more, I would like to help/suggest, but I don't quite understand what's the problem.

It might be I am missing something, but...

1. You can remove bootstrap from /static and from layout.html

2. Add semantic /static and include it in layout.html

3. You can even write your own layout.html and get rid of everything web2py related.

If you remove web2py.js, you can't use LOAD, web2py_ajax and few other things. But it seems you don't really need those.

4. Add vue/angular into /static and include it into layout.html (or use cdn)

You can use JSON to talk with the client:

def my_controller_function():

  data = 123

  return response.json(data=data)

So what pieces of the puzzle are missing here?

Regards,

Marin

[Anthony]

On Wednesday, October 28, 2015 at 11:07:42 AM UTC-4, Ramos wrote:

my inconvenients:

1 - Bootstrap, i need layout.html but dont want bootstrap. How do i get rid of bootstrap or change it to semantic ?

     Bootstrap should not be a constraint but just an add-on. 

How would you do it in a framework that doesn't provide a front-end scaffolding app, such as Flask? That's also how you would do it in web2py. The scaffolding app is just a convenience -- if you don't want it, don't use it and start from scratch.

Anthony

[Daniel Aguayo]

I second this question. pyDAL is very easy, powerful and straightforward to use. Obviously, there are plenty alternative for auth, sessions and such, but I would like to know if others have experience using pyDAL outside web2py on those topics.

[Carlos Cesar Caballero Díaz]

Auth and sessions are more a design and implementation problem than a pyDAL responsability (well, is what I think), I use pyDAL outside web2py with a mail services microfarmework that I built (https://github.com/daxslab/mailProc), and right now I have no complains.

Well, the only thing that I really want right now, is a layer for object oriented use, something like the weppy pyDAL layer should be enough, it will be a impressive improvement to pydal (will convince to many users to use pydal and web2py)

Regards.


El 27/10/15 a las 15:24, Daniel Aguayo escribió:

[Anthony]

Well, the only thing that I really want right now, is a layer for object oriented use, something like the weppy pyDAL layer should be enough, it will be a impressive improvement to pydal (will convince to many users to use pydal and web2py)

What are some examples of things you would envision doing with a "layer for object oriented use" that are more difficult with the pyDAL as is?

[Carlos Cesar Caballero Díaz]

We could use object oriented modeling, we could save our objects directly to the database, we could declare non persistent variables in objects, we could have a better code structure in our apps, we could maintain large models easily, we could reuse or extend model classes easily, we don't will need to worry about the class models files order, we could even load only the models that we need in controllers without write modules...

Object oriented programming is not just use an object oriented programming language, and sadly, with web2py is difficult follow the object oriented paradigm when we develop applications, I like web2py, that's why I am here, but in my personal (and other colleges) opinion, the framework will be better if we could use pydal in an object oriented way.

Greetings.


El 30/10/15 a las 10:49, Anthony escribió:

Well, the only thing that I really want right now, is a layer for object oriented use, something like the weppy pyDAL layer should be enough, it will be a impressive improvement to pydal (will convince to many users to use pydal and web2py)

What are some examples of things you would envision doing with a "layer for object oriented use" that are more difficult with the pyDAL as is?

[Anthony]

On Friday, October 30, 2015 at 3:10:29 PM UTC-4, Carlos Cesar Caballero wrote:

We could use object oriented modeling,

Yes, but the question is, what exactly does that mean to you, and how would it improve things over the current DAL? Can you share a specific example, possibly including pseudo-code?

Also, are you saying you want an ORM, or are you using "object oriented" more generically. If the latter, of course the DAL is already "object oriented" in that most of the API involves instantiating objects and calling methods on them.
 

we could save our objects directly to the database

What do you mean by "objects" here? Are you saying you want to save native Python objects to the database? If so, that would be a feature of the database rather than the abstraction layer interacting with it. Of course, web2py does allow you to store arbitrary objects to any database if they can be pickled or otherwise serialized and deserialized. Can you give an example, and maybe point to how some other favored abstraction layer handles it (e.g., SQLAlchemy)?
 

, we could declare non persistent variables in objects

Not sure what you mean by this. Is this something that can be handled via virtual fields or method fields?
 

, we could have a better code structure in our apps, we could maintain large models easily

Can you be more specific? In web2py, nothing stops you from breaking up model code into multiple modules.
 

, we could reuse or extend model classes easily

This would be one benefit of an ORM approach, though you can already use table inheritance with the DAL, and there are other methods of re-using code (e.g., table methods).
 

, we don't will need to worry about the class models files order

That has nothing to do with the DAL or "object oriented" programming -- that is related to the way web2py executes model files prior to the controller and would affect any type of data model definitions. If you don't want to worry about that, you can move table definitions to modules or use models sub-folders along with response.models_to_run.
 

, we could even load only the models that we need in controllers without write modules...

How so? If using classes, the class declarations would still be executed if they were in a model file. Do you think this would be much more efficient than DAL lazy table declarations?

Object oriented programming is not just use an object oriented programming language, and sadly, with web2py is difficult follow the object oriented paradigm when we develop applications

Are you speaking generally, or just with regard to the DAL? Is it really that you want an ORM and to define database models as classes? If so, again, it would be helpful to understand specific examples of where you find that superior in some way to the DAL.

Anthony

[Vinicius Assef]

The best scenario I see is defining methods to model classes.

For example, centralising queries and business actions like: create_customer(), get_active_employees(), register_student() and so on.

--
Vinicius Assef

On 30 October 2015 at 12:49, Anthony <abas...@gmail.com> wrote:

Well, the only thing that I really want right now, is a layer for object oriented use, something like the weppy pyDAL layer should be enough, it will be a impressive improvement to pydal (will convince to many users to use pydal and web2py)

What are some examples of things you would envision doing with a "layer for object oriented use" that are more difficult with the pyDAL as is?

--

[Anthony]

On Saturday, October 31, 2015 at 8:23:50 PM UTC-4, Vinicius Assef wrote:

The best scenario I see is defining methods to model classes.

For example, centralising queries and business actions like: create_customer(), get_active_employees(), register_student() and so on.

If those are generic functions intended to operate on different tables with common fields, they can simply be implemented as functions. By if you want methods on models themselves, you can do:

@db.employee.add_method.get_active_employees
@db.contractor.add_method.get_active_contractors
def get_active(self):
    return self._db(self.is_active == True).select()
 
active_employees = db.employee.get_active_employees()

Anthony

[Carlos Cesar Caballero Díaz]

The dal is a very good piece of software, and it can done practically everything that any orm can do, but in my opinion, the problem is not what we can do, but how we do it, for example, we have places, and the places have reviews, it will be something like this:

db.define_table('review',
   Field('author'),
   Field('valuea', 'int'),
   Field('valueb', 'int'),
   Field('valuec', 'int'),
   Field('place','reference place'))

db.define_table('place',
   Field('name'),
   Field('description'))

It's clean, there is no problem, but now we need to get the average on a review values, and the average of all places reviews, the we get something like this:

def get_review_average(row):
    # all the code...
    # ...
    return value

db.define_table('review',
   Field('author'),
   Field('valuea', 'int'),
   Field('valueb', 'int'),
   Field('valuec', 'int'),
   Field('place','reference place'))
   Field.Virtual('value', get_review_average))

def get_place_reviews_average(row):
    # all the code calling review.value
    # ...
    return value

db.define_table('place',
   Field('name'),
   Field('description'),
   Field.Virtual('value', get_place_reviews_average))

ok, now is not so clean, the "functions" are before the "variables" declarations, we could add some validations, and we get functions code, fields declarations, and validation code, in that order, when the model grows, the code becomes more difficult to maintain, hardly if the person is not who wrote the code.
Now let's see some weppy-like syntax:

class Review:
    author = Field()
    value = Field('int')
    valuea = Field('int')
    valueb = Field('int')
    place = Field('reference place')

    def get_average(row):
        # all the code...
        # ...
        return value

class Place:
    name = Field()
    description = Field()

    def get_place_reviews_average(row):
        # all the code
        # ...
        return value

db.define_models(Review, Place)

Now the code has a more natural structure, first variables and later functions, we dont care the order, because at the end we declare it using the define_models() function, and we can use inheritance simply like this:

class OtherReview(Review):
    valuebc = Field('int')

Now the code is easier to maintain, and easier to reuse, we only need to copy class files, and extend from them.

This is not an orm, is just current pyDAL with an alternative structure for table declarations.

About the objects, if we could have real orm functionality, we could do things like:

object = db.mytable[id]
object.name = "the name"
object.save()

or

db.mytable.save(object)

The non persistent variables is other thing, in some cases we need to use non persistent variables, like flags, with the virtual or method fields, we can define non persistent values, but we can't edit them.

Greetings.


El 30/10/15 a las 15:34, Anthony escribió:

[Richard Vézina]

Hello,

About webpy example, I think this is readilly possible in web2py, I mean it just maybe a better way to structure your model declaration/defintion... Did you try it with web2py?

Richard

[Carlos Cesar Caballero Díaz]

I am building a plugin for use the weppy code in web2py, It seems to work, but need more coding and testing, I will upload it to github in a couple of minutes.

Greetings.


El 02/11/15 a las 10:02, Richard Vézina escribió:

[Anthony]

On Monday, November 2, 2015 at 9:50:34 AM UTC-5, Carlos Cesar Caballero wrote:

ok, now is not so clean, the "functions" are before the "variables" declarations,

In weppy, you have this (note the need for the @virtualfield decorator):

class Review:
    author = Field()
    value = Field('int')
    valuea = Field('int')
    valueb = Field('int')
    place = Field('reference place')

    @virtualfield('value')

    def get_average(row):
        # all the code...
        # ...
        return value

In web2py, you can do this:

db.define_table('review',
   Field('author'),
   Field('valuea', 'int'),
   Field('valueb', 'int'),
   Field('valuec', 'int'),
   Field('place','reference place'))

def get_review_average(row):
    # all the code...
    # ...
    return

value
db.review.value = Field.Virtual('value', get_review_average)

Same number of lines in the same order. I agree, though, that the first approach looks a little nicer (mainly because the virtual field method is namespaced inside the class), but it's not a dramatic difference (and it would be easy to write a simple decorator to add the virtual field to the table in order to eliminate that last line). Also, the second approach makes it easier to share the virtual field function across multiple tables if needed (without having to worry about multiple inheritance, etc.).

we could add some validations, and we get functions code, fields declarations, and validation code, in that order

As noted above, you can put these in any order you want in web2py. I also find it easier to keep all the attributes (e.g., validators, represent function, etc.) of a given field together, but I suppose that could vary depending on the situation.

I agree that table inheritance is more flexible with the class based method. You can do some basic inheritance with web2py, but it becomes trickier if you need to override specific fields or copy attributes other than fields. I suppose this could be improved in web2py even without using classes -- perhaps it has not been done because there hasn't been much demand.
 

About the objects, if we could have real orm functionality, we could do things like:

object = db.mytable[id]
object.name = "the name"
object.save()

I don't think we need an ORM for that:

row = db.mytable[id]
row.name = 'the name'
row.update_record()

The non persistent variables is other thing, in some cases we need to use non persistent variables, like flags, with the virtual or method fields, we can define non persistent values, but we can't edit them.

First, you can simply do:

row = db.mytable(id)
row.my_non_persistent_variable = 'some value'

Second, you can update virtual field values:

 row.my_virtual_field = 'new value'

Anthony

[Carlos Cesar Caballero Díaz]

Antony, thanks for your answer, there were some things I did not know you could do, but there is just a problem with:

db.define_table('review',
   Field('author'),
   Field('valuea', 'int'),
   Field('valueb', 'int'),
   Field('valuec', 'int'),
   Field('place','reference place'))

def get_review_average(row):
    # all the code...
    # ...
    return

value
db.review.value = Field.Virtual('value', get_review_average),

As you can see in https://github.com/web2py/pydal/issues/304 there is a problem setting method and field attributes directly.




El 02/11/15 a las 11:38, Anthony escribió:

value
db.review.value = Field.Virtual('value', get_review_average),

Same number of lines in the same order. I agree, though, that the first approach looks a little nicer (mainly because the virtual field method is namespaced inside the class), but it's not a dramatic difference (and it would be easy to write a simple decorator to add the virtual field to the table in order to eliminate that last line). Also, the second approach makes it easier to share the virtual field function across multiple tables if needed (without having to worry about multiple inheritance, etc.).

we could add some validations, and we get functions code, fields declarations, and validation code, in that order

As noted above, you can put these in any order you want in web2py. I also find it easier to keep all the attributes (e.g., validators, represent function, etc.) of a given field together, but I suppose that could vary depending on the situation.

I agree that table inheritance is more flexible with the class based method. You can do some basic inheritance with web2py, but it becomes trickier if you need to override specific fields or copy attributes other than fields. I suppose this could be improved in web2py even without using classes -- perhaps it has not been done because there hasn't been much demand.
 

About the objects, if we could have real orm functionality, we could do things like:

object = db.mytable[id]
object.name = "the name"
object.save()

I don't think we need an ORM for that:

row = db.mytable[id]
row.name = 'the name'
row.update_record()

The non persistent variables is other thing, in some cases we need to use non persistent variables, like flags, with the virtual or method fields, we can define non persistent values, but we can't edit them.

First, you can simply do:

row = db.mytable(id)
row.my_non_persistent_variable = 'some value'

Second, you can update virtual field values:

 row.my_virtual_field = 'new value'

Anthony

[Anthony]

On Monday, November 2, 2015 at 12:21:53 PM UTC-5, Carlos Cesar Caballero wrote:

Antony, thanks for your answer, there were some things I did not know you could do, but there is just a problem with:

db.define_table('review',
   Field('author'),
   Field('valuea', 'int'),
   Field('valueb', 'int'),
   Field('valuec', 'int'),
   Field('place','reference place'))

def get_review_average(row):
    # all the code...
    # ...
    return value
db.review.value = Field.Virtual('value', get_review_average),

As you can see in https://github.com/web2py/pydal/issues/304 there is a problem setting method and field attributes directly.

The above will work, and there is no problem setting virtual field attributes directly. The problem in the linked issue was only calling a method field from within a virtual field (and I'm not sure ORMs tend to have the equivalent of virtual fields anyway, so probably not much of a limitation, especially given that there are simple workarounds).

One drawback of the above ordering, though, is that it removes the "laziness" of the table definition (there is a workaround, but not quite as pretty).

Anthony

[Massimo Di Pierro]

Something like this was already implemented 4 years ago when we write a compatibility layer between Django and web2py:

http://web2py.com/AlterEgo/default/download/document.file.08621820-64d8-4db5-a85c-569a647a4437.py

Perhaps you can take some of that code and re-adapt it.

To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscribe@googlegroups.com.