[Toaster] question on spec for "Package included in ..."
Lerner, Dave
dave.lerner at windriver.com
Tue Jan 14 07:20:38 PST 2014
Hi Alex,
Thanks for the pointer. the docs path should use ‘1.5’ not ‘en’.
I will work out the Django model syntax for a many-to-many join either before my first commit or as an action item for my 2nd commit since I’m anxious to get the first commit reviewed and it seems to be a general problem that we may want to implement in other templates.
Working with the database and models from the python interpreter will help. Do you do that? Are there tricks?
Dave Lerner
From: Damian, Alexandru [mailto:alexandru.damian at intel.com]
Sent: Monday, January 13, 2014 2:28 PM
To: Lerner, Dave
Cc: toaster at yoctoproject.org; Ravi Chintakunta (ravi.chintakunta at timesys.com); Reyna, David
Subject: Re: question on spec for "Package included in ..."
Hi,
Just a quick pointer, although I haven't used anything here.
https://docs.djangoproject.com/en/dev/topics/db/examples/many_to_many/
Django supports many to many queries, I'm gonna try tomorrow to get some code working.
Cheers,
Alex
On Mon, Jan 13, 2014 at 6:54 PM, Lerner, Dave <dave.lerner at windriver.com<mailto:dave.lerner at windriver.com>> wrote:
Hi Alex,
>
> You should try not to think in terms of SQL queries, but instead in terms of Django
> QuerySet queries.
>
> The reason for this is that the SQL is often not portable across different database
> backends, which is a requirement for Toaster because we want to give infrastructure
> maintainers freedom on how they install Toaster and which db backends they use.
The query in question is not required any longer after Belen's answer. I didn't know multiple images per build-id were possible.
However, to get a list of a package's dependent packages' names, across a many-to-many relation, in package.html, given a package id, you use two queries to print dependent package names in the template, due to the many-to-many relation...
the reverse lookup :
{% for d in package.package_dependencies_source.all %}
and then the implicit query from package dependency back to package
<a href="#{{d.name<http://d.name>}}">{{d.depends_on.name<http://d.depends_on.name>}}</a><br/>
The standard sql-92 query syntax below will construct a list of package names of dependent packages in a single query rather than the iteration technique above in the package.html template.
'SELECT
orm_package_dependency.id<http://orm_package_dependency.id>,
orm_package.name<http://orm_package.name> name,
orm_package.version version,
orm_package.size size
FROM
orm_package,
orm_package_dependency
WHERE
orm_package_dependency.package_id = %s
AND orm_package_dependency.dep_type == 0
AND orm_package.id<http://orm_package.id> = orm_package_dependency.depends_on_id
', [package_id])
I want to use django model query apis because, as you mention, we can't easily validate whether a query is sql-92 and portable.
I got as far as getting the set of package_dependencies for RDEPENDS packages on somePackageKey
package = Package.get(id=somePackageKey)
package_dependencies = package.package_dependencies_source(dep_type_exact=0)
but couldn't work out syntax to get from this Package_Dependency set to the Package set without iteration in either the client or server. Do you have a trick other than iterating through this list (in either the server or ugh-client?)
-Dave
> The Django QuerySet to get the list of targets for a package can be derived by following
> the relationship across models; i.e you get the build for the specific package, and then
> you get the targets that are images for that build; i.e.
>
>
> > package = Package.objects.filter(pk = id)
>
> > targets = package.build.target_set.filter(is_image=True)
>
> What happens here ?
> For the package model, build is a foreign key to the Build table, so Django will
> populate the instance field with the correct object for Build loaded from the database.
>
> The reverse dependency through a ForeignKey (i.e. many-to-one relationship) is to be
> followed by convention: convert the desired object set model name to lower case, and add
> "_set" to the name. This will create a RelatedManager which is basically a QuerySet that
> can be filtered at will.
>
> The reverse dependency naming convention can be overridden by specifying a
> "related_name" kwarg in the field model definition; this is needed when you have two
> many-to-one relationships with the same object type, i.e. when you map a many-to-many
> relationship, e.g. dependency tables.
>
> Cheers,
>
> Alex
>
>
>
>
>
>
> On Mon, Jan 13, 2014 at 10:50 AM, Barros Pena, Belen <belen.barros.pena at intel.com<mailto:belen.barros.pena at intel.com>>
> wrote:
>
>
>
>
> On 12/01/2014 20:45, "Lerner, Dave" <dave.lerner at windriver.com<mailto:dave.lerner at windriver.com>> wrote:
>
> >Hi Belen, Alex
> >
> >I have a question about the intent of the specification on page 5 of 10
> >of spec design-1.5.1-package-details.pdf listing the images
> > that a package is included in.
> >
> >Packages included in target image
> >If
> > the package is installed in a build target image, the '1.5.1
> >Package
> > details' left content column shows only a list of
> >the
> > target images that include the package.
> >Each
> > target image is a link to the corresponding '1.1.1
> >Included
> > package details' page.
> >If
> > there is more than one target image in the build, they
> >are
> > separated by commas, and listed in ascending
> >alphabetical
> > order.
> >
> >
> >
> >
>
> >The list that should appear is clearly for the package
> >name-version-revision, but should it be a list restricted (as implied by
> > the breadcrumbs) to a single machine/bsp, for example atom-pc vs
> >qemuarm?
>
>
> The list includes only the targets of the selected build. Since there is a
> one to one relationship between builds and machines (you can only build
> for one machine at a time), the answer is yes, the targets listed will
> only apply to one machine. I'll try to explain a bit better: in the
> example shown in the spec (the one you have attached in your e-mail) you
> have selected, from your list of builds, a build for atom-pc that
> completed on 11th Jun 2013 at 15:22. That build built 3 targets:
> core-image-sato, core-image-sato-sdk and core-image-x11, all of them for a
> single machine (atom-pc). The package you have selected (base_files) was
> installed in all 3 targets, and so the 3 of them are listed at the top of
> the page.
>
> I hope this makes sense. If you have any questions, let me know. I'll let
> Alex answer the implementation part.
>
> Cheers
>
> Belén
>
>
> >Do I understand the view spec correctly?
> >
> >For that case, the current form of the database requires a complicated
> >query. I think the logic would have to be (for a passed in
> > build-id-arg, package-id-arg)
> >·
> >Get the machine,
> >buildMachine, for this build-id-arg
> >·
> >Get a list of package.id<http://package.id>¹s for this list of
> >build.id<http://build.id>¹s with this buildMachine
> >·
> >Get a list of target-installed-package.target_ids¹s that are in the
> >include the
> >package.id<http://package.id>¹s above
> >·
> >Return a list of distinct
> >target.target using the target-insalled-package.target_ids list above and
> >also have
> >target.is_image true (1)
> >
> >or using $var embedded
> >sql syntax (for C), after buildMachine,
> >packageName, packageVersion,
> >packageRevision are retrieved...
> >
> >select distinct(orm_target.target) from
> >orm_target, orm_target_installed_package
> >where
> >
> >orm_target.is_image = 1
> >and orm_target.id<http://orm_target.id> =
> >orm_target_installed_package.target_id
> >and
> >orm_target_installed_package.package_id in
> >(select orm_package.id<http://orm_package.id> from
> >orm_build, orm_package
> >where
> >
> >orm_build.machine = $buildMachine
> >and orm_package.name<http://orm_package.name> = $packageName
> >and
> >orm_package.version = $packageVersion
> >and
> >orm_package.revision = $packageRevision
> >and orm_build.id<http://orm_build.id> =
> >orm_package.build_id);
> >
> >Thanks,
> >Dave Lerner
> >
> >
>
>
>
>
>
>
> --
>
> Alex Damian
> Yocto Project
>
> SSG / OTC
--
Alex Damian
Yocto Project
SSG / OTC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/toaster/attachments/20140114/5a172b2b/attachment-0001.html>
More information about the toaster
mailing list