Home/ Questions/Q 7845885
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-02T17:23:46+00:00

I am working on a GAE Python project which has items and transactions on

  • 0

I am working on a GAE Python project which has items and transactions on items.

At first, we tried to use an item kind and a transaction kind with a reference property, but it complicated a lot the queries.

So we switched to an all-in-one version with transaction data stored directly in the item, which resulted in a lot of attributes not being used, as not all items are concerned by transactions.

I expected it to speed up the app, but is this the best way to do this?

Knowing that:

  • we expect to have lots of transactions and many more items.
  • we need to check the transaction status (actually stored in the item’s status).
  • there is only one transaction possible per item but there are many different kind of transactions.

Is there a better solution?

EDIT:

The problem is that I mostly query on the items using the transaction attributes but only 2 where clauses at once maximum , also i update the transaction frequently.

Actually i have some thing like this:

class MyItem(db.Model): 

owner = db.ReferenceProperty(MyUser)  
descr = db.StringProperty()  

status = db.IntegerProperty()  # contains item status / transaction status

tx_actor = db.emailProperty()
tx_token = db.StringProperty()
latest_tx_date = db.DateTimeProperty()
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Since it’s a 1-to-1 mapping, it boils down to how many of the attributes of either the item or transaction you need to query by – those attributes need to be indexed, and how often you write your items or transaction.

    An example where it’s fine to merge them:
    – You rarely write your merged item/transaction object.
    – You query on a small set of attributes, many of the attributes do not need to be indexed.
    – When you do queries, you usually want both the item AND the transaction.

    An example where it’s a bad idea to merge them:
    – Your item has many indexed attributes, but your transaction has very few. But you need to update your transaction frequently. In this case you’d be better off keeping them separate, because every time you write the transaction, you incur all the write costs of updating the indices for the item.

    Another option, if you DON’T need to query on the transaction, is to store the transaction as JSON encoded, then you don’t need to define all the attributes up front. You could also use the Expando class.

    To get better answers, you’d be better off posting examples of what your items/transactions look like, and the types of queries you’d want to run.

    • 0