Re: [SQLObject] Class Design Problems

[Rick F. <rf...@im...>]

I'm not sure but it sounds like you want a SUM().
Do you want SUM(showroom, transit, back)?
What is 'main'?

Have you tried this:

class Product(SQLObject):
     name = UnicodeCol()
     description = UnicodeCol()
     price = CurrencyCol()
     stock = ForeignKey('Stock')

     def _get_main(self):
         return self.stock.main

class Stock(SQLObject):
     showroom = IntCol()
     transit = IntCol()
     back = IntCol()

     def _get_main(self):
         """
         I'm assuming main is a sum of the other 3.
         """
         return showroom + transit + back

Is this what you were looking for?

--
rick

On Wed, 19 Oct 2005, Koen Bok wrote:

> Let's say I have a class Product like this:
>
> class Product(SQLObject):
>    name = UnicodeCol()
>    description = UnicodeCol()
>    price = CurrencyCol()
>
> I need this products to have Stock Amounts. The amounts should depend on the 
> physical location of the stock, and the 'virtual' stock per location like 
> Showroom, Returned, Main.
>
> What I now have is (for each physical location):
>
> class StockAmsterdam(SQLObject):
>    main = IntCol()
>    showroom = IntCol()
>    transit = IntCol()
>    back = IntCol()
>    product = ForeignKey('Product')
>
> Two problems arise:
>
> - Whenever I make a list of products and access their stock.main key, it does 
> one query. I need this to be done in one big query. So I thought joins would 
> do the trick:
>
> self.visibleProducts = list(
>    Product.select(AND(*[OR(
>        Product.q.name.contains(str(string.strip())),
>        Product.q.description.contains(str(string.strip())))
>    for string in searchList]),
>    join=RIGHTJOINOn(
>        Product,
>        StockAmsterdam,
>        Product.q.id == StockAmsterdam.q.productID)))
>
> But now when I try to access the someProduct.main it does not return the 
> joined main value. How should I do this?
>
> - This is a dirty way to implement this. I have to add another table for 
> every new physical location and an extra table column for every new 'virtual' 
> stock. Maybe anyone has a better idea for this?