You're right ! Also, you usually get notices in the docs where things appeared/changed in 1.6 as to 1.5 version, so it's a bit helpful to look at the dev version to see what's gonna happen on our next Django version upgrade.
Alex On Tue, Jan 14, 2014 at 3:22 PM, Lerner, Dave <[email protected]>wrote: > Correction: I meant the docs path should use '1.5' not 'dev'. > > > -----Original Message----- > > From: Lerner, Dave > > Sent: Tuesday, January 14, 2014 9:21 AM > > To: 'Damian, Alexandru' > > Cc: [email protected]; Ravi Chintakunta ( > [email protected]); Reyna, > > David > > Subject: RE: question on spec for "Package included in ..." > > > > 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:[email protected]] > > Sent: Monday, January 13, 2014 2:28 PM > > To: Lerner, Dave > > Cc: [email protected]; Ravi Chintakunta ( > [email protected]); 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 <[email protected]> > 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 < > [email protected]> > > > wrote: > > > > > > > > > > > > > > > On 12/01/2014 20:45, "Lerner, Dave" <[email protected]> > 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 > -- Alex Damian Yocto Project SSG / OTC
_______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
