Relationships and more classmethods in DataObjects
iGL
I wonder if there is a possibility to handle relationships in QLime. I
would really enjoy a Rails AR functionality (has_many, belongs_to,
etc.,) in QLime.
Also, why don't put an emphasis on a chance to add custom classmethods
to DataObjects, instead of using them as empty placeholders? E.g.,
class Article(DataObject):
@classmethod
def find_last_five( cls ):
return cls.find( **needed_options)
Sort of.
What do you think about adding such functionalities as relationships to
QLime? My tests show they are pretty feasible...
Greetings,
Giorgi
P.S. I briefly discussed in my blog (http://www.libera-me.org) the
reasons why I'd like having it and would much appreciate your comment.
Shalabh Chaturvedi
>
> Hi Shalabh,
> I wonder if there is a possibility to handle relationships in QLime. I
> would really enjoy a Rails AR functionality (has_many, belongs_to,
> etc.,) in QLime.
Hmm, as I understand, relationships are already there so I'm not sure
what you mean. Could you give example code of how you want to use this
feature?
An example of has_many is here: http://qlime.org/example.rst (see
Joined Tables section). The 'relation' is not defined in the Python
class but in the underlying data objectclass.
Does active record allow you to do something more than this?
> Also, why don't put an emphasis on a chance to add custom classmethods
> to DataObjects, instead of using them as empty placeholders? E.g.,
> class Article(DataObject):
> @classmethod
> def find_last_five( cls ):
> return cls.find( **needed_options)
>
You can already do this - I'll definitely add more examples of such
usage.
Cheers,
Shalabh
iGL
1. Yes, I know, how to use joins and composite_obclass to handle
relationships. The point is that it's a common operation. Therefore,
probably, QLime should have functions or classes to avoid repetitions.
For example, I use XDataObject class ( see it at
http://tables.self-propelled-python.com/XDataObject.py.txt) It,
however, relies on connection objects, which are not bound to the class
but rather imported from the conventional module (db_server.py.txt)
Now, one can do:
class Articles( XDataObject ):
has_many = "Comments"
local_key = 'id'
foreign_key = 'article_id'
and then,
A = Articles.new().find_one( id = 1 )
for c in A.get_comments:
print c.title
For the time being, I repeat one thing: cls already has
has_many.lower() attribute to handle subobname, but self relies on get_
prefix; other problem is that local and foreugn keys should be
optional, if foreign key is set up in db, with sql statements.
(Articles and Comments are taken fro typo's (ruby blog) sql backend;
test_backend.sql.txt, from the same url)
2. Yes, that's exactly what I mean: the only thing needed is to update
docs.
Greetings,
Giorgi
Shalabh Chaturvedi
>
> Hi Shalabh,
>
> 1. Yes, I know, how to use joins and composite_obclass to handle
> relationships. The point is that it's a common operation. Therefore,
> probably, QLime should have functions or classes to avoid repetitions.
> For example, I use XDataObject class ( see it at
> http://tables.self-propelled-python.com/XDataObject.py.txt) It,
> however, relies on connection objects, which are not bound to the class
> but rather imported from the conventional module (db_server.py.txt)
> Now, one can do:
> class Articles( XDataObject ):
> has_many = "Comments"
> local_key = 'id'
> foreign_key = 'article_id'
>
> and then,
> A = Articles.new().find_one( id = 1 )
> for c in A.get_comments:
> print c.title
>
Ah, I see what you are saying. The idea behind DataObject is that the
underlying data store does not matter. For example it might be LDAP or
an object database and you are able to switch the store easily, without
any changes to DataObject or code above it. This means data store
specific artifacts should not appear in DataObject. However since major
usage is relational database - it looks like a good idea to make that
easier - let me think about how this can be done.
Thanks for your comments!
Shalabh