What do you think about "abstract" entity option like Abstract base classes feature in Django ORM ?

[KLEIN Stéphane]

Hi,

what do you think about "abstract" entity option like Abstract base
classes feature in Django ORM (http://docs.djangoproject.com/en/dev/
topics/db/models/#id6) ?

I need this feature, if you think it is useful feature, I going to
work on.

Regards,
Stephane

[Gaetan de Menten]

You can already have a similar behavior by using a custom base class:
http://elixir.ematia.de/trac/browser/elixir/trunk/tests/test_custombase.py#L81

The only shortcoming I know of for this approach is that you can't
have an abstract entity which inherits from a non-abstract one, but I
don't think this is very useful in practice.

--
Gaëtan de Menten
http://openhex.org

[KLEIN Stéphane]

On 20 avr, 16:03, Gaetan de Menten <gdemen...@gmail.com> wrote:

> On Mon, Apr 20, 2009 at 15:42, KLEIN Stéphane <klein.steph...@gmail.com> wrote:
> > what do you think about "abstract" entity option like Abstract base
> > classes feature in Django ORM (http://docs.djangoproject.com/en/dev/
> > topics/db/models/#id6) ?
>
> > I need this feature, if you think it is useful feature, I going to
> > work on.
>

> You can already have a similar behavior by using a custom base class:http://elixir.ematia.de/trac/browser/elixir/trunk/tests/test_customba...

>
> The only shortcoming I know of for this approach is that you can't
> have an abstract entity which inherits from a non-abstract one, but I
> don't think this is very useful in practice.

This is a working dirty example (http://pypaste.com/
4ApPiBlwAHHcNJ6JNQPOSw) :

::

from elixir import *

metadata.bind = 'sqlite:///test.db'

class BaseA(object):
field_a = Field(Unicode())

class AbstractA(BaseA):
__metaclass__ = EntityMeta

class AbstractB(BaseA):
__metaclass__ = EntityMeta
field_b = Field(Unicode())

class C(AbstractB):
field_c = Field(Unicode())

class D(AbstractB):
field_d = Field(Unicode())

class E(AbstractA):
field_e = Field(Unicode())

if __name__ == '__main__':
setup_all()
create_all()

This is what I would like (http://pypaste.com/
2f7cBSGCSiIsku6ZDDM0vU) :

::

from elixir import *

metadata.bind = 'sqlite:///test.db'

class AbstractA(Entity):
using_options(abstract = True)

field_a = Field(Unicode())

class AbstractB(Entity):
using_options(abstract = True)

field_b = Field(Unicode())

class C(AbstractB):
field_c = Field(Unicode())

class D(AbstractB):
field_d = Field(Unicode())

class E(AbstractA):
field_e = Field(Unicode())

if __name__ == '__main__':
setup_all()
create_all()

In my personal stuff, I've many generic model with multi inheritance.
This is why I need this feature.

What do you think about this 'using_options(abstract = True)'
feature ?

Regards,
Stephane

[Gaetan de Menten]

On Mon, Apr 20, 2009 at 20:01, KLEIN Stéphane <klein.s...@gmail.com> wrote:
> On 20 avr, 16:03, Gaetan de Menten <gdemen...@gmail.com> wrote:
>> On Mon, Apr 20, 2009 at 15:42, KLEIN Stéphane <klein.steph...@gmail.com> wrote:

>> > what do you think about "abstract" entity option like Abstract base
>> > classes feature in Django ORM (http://docs.djangoproject.com/en/dev/
>> > topics/db/models/#id6) ?

>> You can already have a similar behavior by using a custom base class:http://elixir.ematia.de/trac/browser/elixir/trunk/tests/test_customba...

>>
>> The only shortcoming I know of for this approach is that you can't
>> have an abstract entity which inherits from a non-abstract one, but I
>> don't think this is very useful in practice.

> This is a working dirty example (http://pypaste.com/
> 4ApPiBlwAHHcNJ6JNQPOSw) :

I know how it works... But in case you were trying to prove the
limitation I described doesn't exist, in your example BaseA is
effectively abstract since it won't create tables.

> This is what I would like (http://pypaste.com/
> 2f7cBSGCSiIsku6ZDDM0vU) :
>
>    from elixir import *
>
>    metadata.bind = 'sqlite:///test.db'
>
>    class AbstractA(Entity):
>        using_options(abstract = True)
>
>        field_a = Field(Unicode())
>
>    class AbstractB(Entity):
>        using_options(abstract = True)
>
>        field_b = Field(Unicode())
>
>    class C(AbstractB):
>        field_c = Field(Unicode())
>
>    class D(AbstractB):
>        field_d = Field(Unicode())
>
>    class E(AbstractA):
>        field_e = Field(Unicode())
>
>    if __name__ == '__main__':
>        setup_all()
>        create_all()
>
> In my personal stuff, I've many generic model with multi inheritance.
> This is why I need this feature.
>
> What do you think about this 'using_options(abstract = True)'
> feature ?

You just want a different syntax to do the same as the __metaclass__
approach? What's wrong with that syntax?

[KLEIN Stéphane]

On 21 avr, 11:42, Gaetan de Menten <gdemen...@gmail.com> wrote:

Sorry, I've make one mistake in my example, I've fixed it :

http://pypaste.com/2f7cBSGCSiIsku6ZDDM0vU

In this example, I've five class.

In dirty example (http://pypaste.com/4ApPiBlwAHHcNJ6JNQPOSw) I've six
class to do the same thing.

> You just want a different syntax to do the same as the __metaclass__
> approach? What's wrong with that syntax?

Now, do you see the difference ?

Regards,
Stephane

[KLEIN Stéphane]

My patch is here : http://elixir.ematia.de/trac/ticket/89

[KLEIN Stéphane]

I have attached a new patch to this ticket with :

* some document
* test_simple_relation2 fixed

Regards,
Stephane