ahuston-0/hydra
1
0
Fork 0
Code Issues Pull Requests 1 Packages Projects Releases Wiki Activity
hydra/src/lib/Hydra/Schema/ViewJobs.pm

166 lines
2.5 KiB
Perl
Raw Normal View History

* Renaming "release sets" to "views" (not finished yet). Having releases as a dynamic view on the database was misguided, since doing thing like adding a new job to a release set will invalidate all old releases. So we rename release sets to views, and we'll reintroduce releases as separate, static entities in the database.
2009-10-15 21:35:19 +00:00
package Hydra::Schema::ViewJobs;
* Basic release management: releases are now dynamically computed as database queries from a set of jobs that have to be in a release. E.g. a patchelf release might consist of the jobs "tarball", "build", and "rpm_fedora10i386". Here the first job ("tarball") is the primary job: all the others have it as an input. The primary job supplies the identity of the release.
2008-11-27 15:16:06 +00:00
2009-10-23 15:05:16 +00:00
# Created by DBIx::Class::Schema::Loader
# DO NOT MODIFY THE FIRST PART OF THIS FILE
* Basic release management: releases are now dynamically computed as database queries from a set of jobs that have to be in a release. E.g. a patchelf release might consist of the jobs "tarball", "build", and "rpm_fedora10i386". Here the first job ("tarball") is the primary job: all the others have it as an input. The primary job supplies the identity of the release.
2008-11-27 15:16:06 +00:00
use strict;
use warnings;
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
use base 'DBIx::Class::Core';
=head1 NAME
Hydra::Schema::ViewJobs
=cut
* Basic release management: releases are now dynamically computed as database queries from a set of jobs that have to be in a release. E.g. a patchelf release might consist of the jobs "tarball", "build", and "rpm_fedora10i386". Here the first job ("tarball") is the primary job: all the others have it as an input. The primary job supplies the identity of the release.
2008-11-27 15:16:06 +00:00
* Renaming "release sets" to "views" (not finished yet). Having releases as a dynamic view on the database was misguided, since doing thing like adding a new job to a release set will invalidate all old releases. So we rename release sets to views, and we'll reintroduce releases as separate, static entities in the database.
2009-10-15 21:35:19 +00:00
__PACKAGE__->table("ViewJobs");
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
=head1 ACCESSORS
=head2 project
data_type: text
default_value: undef
is_foreign_key: 1
is_nullable: 0
size: undef
=head2 view_
data_type: text
default_value: undef
is_foreign_key: 1
is_nullable: 0
size: undef
=head2 job
data_type: text
default_value: undef
is_nullable: 0
size: undef
=head2 attrs
data_type: text
default_value: undef
is_nullable: 0
size: undef
=head2 isprimary
data_type: integer
default_value: 0
is_nullable: 0
size: undef
=head2 description
data_type: text
default_value: undef
is_nullable: 1
size: undef
=head2 jobset
data_type: text
default_value: undef
is_nullable: 0
size: undef
=head2 autorelease
data_type: integer
default_value: 0
is_nullable: 0
size: undef
=cut
* Basic release management: releases are now dynamically computed as database queries from a set of jobs that have to be in a release. E.g. a patchelf release might consist of the jobs "tarball", "build", and "rpm_fedora10i386". Here the first job ("tarball") is the primary job: all the others have it as an input. The primary job supplies the identity of the release.
2008-11-27 15:16:06 +00:00
__PACKAGE__->add_columns(
"project",
* Added a maintainers field to the Builds table. * Regenerated the schema bindings with the latest DBIx::Class.
2009-07-07 13:59:59 +00:00
{
data_type => "text",
default_value => undef,
is_foreign_key => 1,
is_nullable => 0,
size => undef,
},
* Renaming "release sets" to "views" (not finished yet). Having releases as a dynamic view on the database was misguided, since doing thing like adding a new job to a release set will invalidate all old releases. So we rename release sets to views, and we'll reintroduce releases as separate, static entities in the database.
2009-10-15 21:35:19 +00:00
"view_",
* Added a maintainers field to the Builds table. * Regenerated the schema bindings with the latest DBIx::Class.
2009-07-07 13:59:59 +00:00
{
data_type => "text",
default_value => undef,
is_foreign_key => 1,
is_nullable => 0,
size => undef,
},
* Basic release management: releases are now dynamically computed as database queries from a set of jobs that have to be in a release. E.g. a patchelf release might consist of the jobs "tarball", "build", and "rpm_fedora10i386". Here the first job ("tarball") is the primary job: all the others have it as an input. The primary job supplies the identity of the release.
2008-11-27 15:16:06 +00:00
"job",
* Added a maintainers field to the Builds table. * Regenerated the schema bindings with the latest DBIx::Class.
2009-07-07 13:59:59 +00:00
{
data_type => "text",
default_value => undef,
is_nullable => 0,
size => undef,
},
* Basic release management: releases are now dynamically computed as database queries from a set of jobs that have to be in a release. E.g. a patchelf release might consist of the jobs "tarball", "build", and "rpm_fedora10i386". Here the first job ("tarball") is the primary job: all the others have it as an input. The primary job supplies the identity of the release.
2008-11-27 15:16:06 +00:00
"attrs",
* Added a maintainers field to the Builds table. * Regenerated the schema bindings with the latest DBIx::Class.
2009-07-07 13:59:59 +00:00
{
data_type => "text",
default_value => undef,
is_nullable => 0,
size => undef,
},
* Basic release management: releases are now dynamically computed as database queries from a set of jobs that have to be in a release. E.g. a patchelf release might consist of the jobs "tarball", "build", and "rpm_fedora10i386". Here the first job ("tarball") is the primary job: all the others have it as an input. The primary job supplies the identity of the release.
2008-11-27 15:16:06 +00:00
"isprimary",
* Added a maintainers field to the Builds table. * Regenerated the schema bindings with the latest DBIx::Class.
2009-07-07 13:59:59 +00:00
{ data_type => "integer", default_value => 0, is_nullable => 0, size => undef },
* Basic release management: releases are now dynamically computed as database queries from a set of jobs that have to be in a release. E.g. a patchelf release might consist of the jobs "tarball", "build", and "rpm_fedora10i386". Here the first job ("tarball") is the primary job: all the others have it as an input. The primary job supplies the identity of the release.
2008-11-27 15:16:06 +00:00
"description",
* Added a maintainers field to the Builds table. * Regenerated the schema bindings with the latest DBIx::Class.
2009-07-07 13:59:59 +00:00
{
data_type => "text",
default_value => undef,
is_nullable => 1,
size => undef,
},
* Add the name of the jobset to ReleaseSetJobs, otherwise we can't distinguish between jobs with the same name in different jobsets (e.g. "trunk" vs "stdenv-branch" for Nixpkgs). * Renamed the "attrName" field of Builds to "job". * Renamed the "id" field of BuildSteps to "build".
2009-03-12 14:18:30 +00:00
"jobset",
* Added a maintainers field to the Builds table. * Regenerated the schema bindings with the latest DBIx::Class.
2009-07-07 13:59:59 +00:00
{
data_type => "text",
default_value => undef,
is_nullable => 0,
size => undef,
},
* Renaming "release sets" to "views" (not finished yet). Having releases as a dynamic view on the database was misguided, since doing thing like adding a new job to a release set will invalidate all old releases. So we rename release sets to views, and we'll reintroduce releases as separate, static entities in the database.
2009-10-15 21:35:19 +00:00
"autorelease",
{ data_type => "integer", default_value => 0, is_nullable => 0, size => undef },
* Basic release management: releases are now dynamically computed as database queries from a set of jobs that have to be in a release. E.g. a patchelf release might consist of the jobs "tarball", "build", and "rpm_fedora10i386". Here the first job ("tarball") is the primary job: all the others have it as an input. The primary job supplies the identity of the release.
2008-11-27 15:16:06 +00:00
);
* Renaming "release sets" to "views" (not finished yet). Having releases as a dynamic view on the database was misguided, since doing thing like adding a new job to a release set will invalidate all old releases. So we rename release sets to views, and we'll reintroduce releases as separate, static entities in the database.
2009-10-15 21:35:19 +00:00
__PACKAGE__->set_primary_key("project", "view_", "job", "attrs");
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
=head1 RELATIONS
=head2 project
Type: belongs_to
Related object: L<Hydra::Schema::Projects>
=cut
__PACKAGE__->belongs_to("project", "Hydra::Schema::Projects", { name => "project" }, {});
=head2 view
Type: belongs_to
Related object: L<Hydra::Schema::Views>
=cut
* Basic release management: releases are now dynamically computed as database queries from a set of jobs that have to be in a release. E.g. a patchelf release might consist of the jobs "tarball", "build", and "rpm_fedora10i386". Here the first job ("tarball") is the primary job: all the others have it as an input. The primary job supplies the identity of the release.
2008-11-27 15:16:06 +00:00
__PACKAGE__->belongs_to(
* Renaming "release sets" to "views" (not finished yet). Having releases as a dynamic view on the database was misguided, since doing thing like adding a new job to a release set will invalidate all old releases. So we rename release sets to views, and we'll reintroduce releases as separate, static entities in the database.
2009-10-15 21:35:19 +00:00
"view",
"Hydra::Schema::Views",
{ name => "view_", project => "project" },
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
{},
* Basic release management: releases are now dynamically computed as database queries from a set of jobs that have to be in a release. E.g. a patchelf release might consist of the jobs "tarball", "build", and "rpm_fedora10i386". Here the first job ("tarball") is the primary job: all the others have it as an input. The primary job supplies the identity of the release.
2008-11-27 15:16:06 +00:00
);
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
# Created by DBIx::Class::Schema::Loader v0.05003 @ 2010-02-25 10:29:41
# DO NOT MODIFY THIS OR ANYTHING ABOVE! md5sum:+aFIv2sSlgMWKcQuWnq0fg
* Basic release management: releases are now dynamically computed as database queries from a set of jobs that have to be in a release. E.g. a patchelf release might consist of the jobs "tarball", "build", and "rpm_fedora10i386". Here the first job ("tarball") is the primary job: all the others have it as an input. The primary job supplies the identity of the release.
2008-11-27 15:16:06 +00:00
1;
Reference in New Issue Copy Permalink