Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #858 (closed enhancement: wontfix)

Opened 13 years ago

Last modified 10 years ago

so_to_dict function to support joins

Reported by: jiri.popek@… Owned by: alberto
Priority: normal Milestone: 1.x
Component: TurboGears Version: 0.9a5
Severity: normal Keywords: so_to_dict, joins


TextField? automatically fills itself when form is to be displayed. The data to fill the form is given by dictionary created from SQLObject class using function so_to_dict(). When we need to automatically select items within MultipleSelectField? according data from join, we need to patch function so_to_dict() to return dictionary containing also joins (not columns only).


class Genre(SQLObject):
    titles = RelatedJoin('Title')
class Title(SQLObject):
    genres = RelatedJoin('Genre')

def get_all_genres():
        return [(int(a.id), "%s" % a.name) for a in Genre.select()]

class TitleFields(WidgetsList):
    genres = MultipleSelectField(name='genres', 
                options=get_all_genres, validator=Int())
class TitleForm(TableForm):
    fields = TitleFields()

${form.display(obj, action=action)}

class TitleCont(BaseDataController):
    form_widget = TitleForm()
    def edit(self, obj):
        value = so_to_dict(obj)
        return dict(form=self.form_widget, obj=value, action="save")


database.py.diff Download (535 bytes) - added by jiri.popek@… 13 years ago.

Change History

Changed 13 years ago by jiri.popek@…

comment:1 Changed 13 years ago by alberto

I'm not sure if it would be a good idea to unfold all joins by default for any SO because a join can have potentially *many* related rows.

I can think of two possible solutions:

  • Implement so_to_dict as a generic function, with the current implementation as a default for SQLObjects with room for further specialization for app specific objects.
  • Remove so_to_dict completely and use jsonify instead, which basically does "the right thing" on SOs (needs further speciallization for InheritableSQLObjects, I have a patch for that).


comment:2 Changed 13 years ago by kevin

  • Summary changed from [PATCH] so_to_dict function to support joins to so_to_dict function to support joins

Alberto's right... there are quite a few use cases where picking up all related objects would be way too expensive. Using a generic function makes sense.

I also wonder why you're using so_to_dict rather than just passing the sqlobject itself as the value for the form?

I'm removing the [PATCH] designator, but I'm leaving the ticket open for further thought along these lines.

comment:3 Changed 13 years ago by jorge.vargas

  • Milestone set to 1.1

comment:4 Changed 12 years ago by alberto

  • Status changed from new to assigned
  • Owner changed from anonymous to alberto

I think the best solution would be to make so_to_dict a generic function with the current implementation as a default and add support on the way for InheritableSQLObjects and, why not, leave the door open to SA mapped classes will need to change the name to something more meaningful if we want to support SA, suggestions?

jsonify could delegate to this function to handle SQLObjects in order to avoid code duplication.


comment:5 Changed 12 years ago by alberto

  • Milestone changed from 1.1 to __unclassified__

Batch moved into unclassified from 1.1 to properly track progress on the later

comment:6 Changed 10 years ago by jorge.vargas

  • Milestone changed from __unclassified__ to 1.x

comment:7 Changed 10 years ago by Chris Arndt

  • Status changed from assigned to closed
  • Resolution set to wontfix

Cruft ticket. Anyway, I don't think this belongs into the scope of TurboGears. If you need a custom way to turn your model objects into dicts, write appropriate code in json.py or add a base class to your model classes that provides a method for this.

Note: See TracTickets for help on using tickets.