django-polymorphic discussion log of IRC

django-shop-polymorphic.txt

<ionelmc> single currency, mail shiping for start - however there's need for some various discounting schemes for products and some fancy category scheme i think
<ionelmc> so the Product.get_specific implementation is going to be replaced by djnago-polymorphic ?
<Tribaal> ionelmc, I'll keep the polymorphic branhc around, I think it's really elegan
<Tribaal> so I'll test more before I make a decision
<ionelmc> if i need to manage stock i have to build my own models for that right?
<Tribaal> but generally I thin kit's the right way to go, yeah
<Tribaal> ionelmc, yes, for the time being
<Tribaal> for stock I think there should be a new type of plugin almost (like a transaction plugin)
<Tribaal> it would be useful for vouchers too, for instance
<Tribaal> for the time being the stock needs to be handled in your own models, however
<Tribaal> for categories there is django-shop-simplecategories (should be enough for many cases)
<Tribaal> and the discounting schemes are one of the reasons why I started with django-shop (it's designed to make discounts really easy, IMHO)
<ionelmc> so right now the Product model needs to have a onetoone field on subclasses right ?  - however it wouldn't support more than 1 level of inheritance since the reverse descriptors that are added by the O2OField aren't recurrent acrosss the whole inheritance tree
<ionelmc> the docstring on get_specific says the contrary "        This magic method returns this as an instance of the most specific        decendant in the inheritence tree."
<ionelmc> the polymorphic branch is usable right now or i'd better start a project on the master branch ?
<Tribaal> ionelmc, as you wish, changing from/to polymorphic changes almost nothing
<Tribaal> ionelmc, no, there is No oneToOne field :) the subclass has a relation to the superclass, and get_specific calls the relation's reverse
<Tribaal> (you don't need to explicitely declare the child->parent relation since the ORM does this for you when you create concrete inheritence
<Tribaal> therefore, it works :)
<Tribaal> but it's a bit ugly to handle querysets: lists cannot be mixed, so you need to query the superclass, then make one query per object you wish to downcast
<Tribaal> (if you wish to downcast them)
<Tribaal> so you need N+1 query (N = number of objects)
<Tribaal> with polymorphic, you need N+1 queries, but where N is the number of *subclasses*, which is of course much more efficient
<Tribaal> and finally, that means you can have your own model appear in lists (with the current solution you cannot easily add a field to the base product without doing something really ugly like monkeypatching)
<ionelmc> oh right :)
<ionelmc> well
<ionelmc> gtg for now, thanks for the info
<Tribaal> no problems :)
* ionelmc has quit (Quit: Leaving.)
<Tribaal> I guess I should save the log somewhere, it might come in handy :)
* dzen has quit (Remote host closed the connection)
* mbrochh has quit (Quit: Verlassend)
* ionelmc (~jmc@unaffiliated/ionelmc) has joined #django-shop
* ojii has quit (Remote host closed the connection)
* ojii ([email protected]) has joined #django-shop
* ChanServ gives channel operator status to ojii
<bmihelac> I just checked django-polymorphic, it seems god send
<bmihelac> I hope it doesnt touch admin and it doesn't have issues with joins