[Toaster] question on spec for "Package included in ..."

Damian, Alexandru alexandru.damian at intel.com
Mon Jan 13 12:27:34 PST 2014


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>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}}">{{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,
>                 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 = 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>
> > wrote:
> >
> >
> >
> >
> >       On 12/01/2014 20:45, "Lerner, Dave" <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¹s for this list of
> >       >build.id¹s with this buildMachine
> >       >·
> >       >Get a list of target-installed-package.target_ids¹s that are in
> the
> >       >include the
> >       >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 =
> >       >orm_target_installed_package.target_id
> >       >and
> >       >orm_target_installed_package.package_id in
> >       >(select orm_package.id from
> >       >orm_build, orm_package
> >       >where
> >       >
> >       >orm_build.machine = $buildMachine
> >       >and orm_package.name = $packageName
> >       >and
> >       >orm_package.version = $packageVersion
> >       >and
> >       >orm_package.revision = $packageRevision
> >       >and 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/20140113/c373faee/attachment.html>


More information about the toaster mailing list