Similarly TestRun.get() only provides product_version but no product_id.

See following relationships:

            foreignkey
TestCase ---------------> TestCaseCategory
                               /
                              / 
                             /foreignkey
                            /
                           /
                        Product

To obtain product info via TestCase.get(), we need first to get category from an intermediate table 'testcasecategory', then get product info through category.

By calling rpc functions, we could provide the first level foreignkey(name & id) but not any more, or it would be too coupled.
I suggest to get additional information by calling other methods.

What's your opinion?

> By calling rpc functions, we could provide the first level
> foreignkey(name & id) but not any more, or it would be too
> coupled.  I suggest to get additional information by calling
> other methods.

What do you exactly mean by "first level foreign key(name & id)"?
For my use case product_id would be completely sufficient. No need
to provide the product name or anything else.

An example scenario can be updating a test build of a test run: I
would like to be able to fetch test run data (including product):

    hash = TestRun.get(1234)

then get the new build id

    build_id = Build.check_build('SomeBuildName', hash["product_id"])

and then simply update the build using

    TestRun.update(1234, {product: hash["product_id"], build_id})

without need to perform additional xmlrpc call to look up the
actual product id.

by saying 'first level foreignkey', see following:

 
             foreignkey
TestRun ------------------> TestBuild
                                /
                               / 
                              /foreignkey
                             /
                            /
                         Product

It's bundled to current db table relationships, to provide product_id via TestRun.get(), need first get the run's build and then fetch product via build.

By calling one function(e.g. TestRun.get) and get all fks and fks' fks and so on would be too coupled, I think.

In above graph, For TestRun, 'first level foreignkey' means 'TestBuild' model, and 'Product' is a second level foreignkey(TestBuild's foreignkey)

I see, thanks for making the relations clear. One more question:
Is the default_product_version also a foreign key? I was quite
surprised that TestPlan.get() and TestRun.get() return string
values for the default product version (e.g. '5.7') but update()
functions require version id. If it is a foreign key, could it be
included in the get() results as well?

The product_version for a TestRun is not a foreign key, it's a field and will be stored during run's creation, thus by calling TestRun.get() will get product_version but not product.

TCMS's db structure is originated from Testopia and we found a few problems/bugs bundled to db schema, need to refactor/refine codes to fix them.

(In reply to comment #7)
> The product_version for a TestRun is not a foreign key, it's a
> field and will be stored during run's creation, thus by calling
> TestRun.get() will get product_version but not product.

Oh! I see, Testopia legacy... That's sad.

However, I suggest to keep this bug open to track the default
product version cleanup. I suppose TestRun & TestPlan field
product_version should be changed to a foreign key (or a new
product_version_id added) and synced to the "field value".

As far as xmlrpc API is concerned, new product_version_id should
be returned when calling TestRun.get() and TestPlan.get(). Agree?

Agreed, versions should be stored as fk instead of static values.