Gleipnir/nidus-sync
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
nidus-sync/db/dbinfo/note_audio.bob.go

262 lines
5.7 KiB
Go
Raw Normal View History

Add ability to make LLM agent forget the conversation history This is extremely useful for testing. In order to do this I needed to actually deploy the migration to a bob fork so I could start to add support for behaviors I really want. Specifically the ability to search for ids in a slice.
2026-01-27 18:44:02 +00:00
// Code generated by BobGen psql v0.42.5. DO NOT EDIT.
Remove old FieldSeeker tables, use v2 generated tables. This requires a bunch of changes since the types on these tables are much closer to the underlying types of the Fieldseeker data we are getting back from the API. I now need to use proper UUID types everywhere, which means I had to modify the bob gen config to consistently use google UUID, my UUID library of choice. I also had to add the organization_id to all the fieldseeker tables since we rely on them existing for some of our compound queries. There were some changes to the API type signatures to get things to build. I may yet regret those.
2025-12-24 17:49:39 -07:00
// This file is meant to be re-generated in place and/or deleted at any time.
package dbinfo
import "github.com/aarondl/opt/null"
var NoteAudios = Table[
noteAudioColumns,
noteAudioIndexes,
noteAudioForeignKeys,
noteAudioUniques,
noteAudioChecks,
]{
Schema: "",
Name: "note_audio",
Columns: noteAudioColumns{
Created: column{
Name: "created",
DBType: "timestamp without time zone",
Default: "",
Comment: "",
Nullable: false,
Generated: false,
AutoIncr: false,
},
CreatorID: column{
Name: "creator_id",
DBType: "integer",
Default: "",
Comment: "",
Nullable: false,
Generated: false,
AutoIncr: false,
},
Deleted: column{
Name: "deleted",
DBType: "timestamp without time zone",
Default: "NULL",
Comment: "",
Nullable: true,
Generated: false,
AutoIncr: false,
},
DeletorID: column{
Name: "deletor_id",
DBType: "integer",
Default: "NULL",
Comment: "",
Nullable: true,
Generated: false,
AutoIncr: false,
},
Duration: column{
Name: "duration",
DBType: "real",
Default: "",
Comment: "",
Nullable: false,
Generated: false,
AutoIncr: false,
},
OrganizationID: column{
Name: "organization_id",
DBType: "integer",
Default: "",
Comment: "",
Nullable: false,
Generated: false,
AutoIncr: false,
},
Transcription: column{
Name: "transcription",
DBType: "text",
Default: "NULL",
Comment: "",
Nullable: true,
Generated: false,
AutoIncr: false,
},
TranscriptionUserEdited: column{
Name: "transcription_user_edited",
DBType: "boolean",
Default: "",
Comment: "",
Nullable: false,
Generated: false,
AutoIncr: false,
},
Version: column{
Name: "version",
DBType: "integer",
Default: "",
Comment: "",
Nullable: false,
Generated: false,
AutoIncr: false,
},
UUID: column{
Name: "uuid",
DBType: "uuid",
Default: "",
Comment: "",
Nullable: false,
Generated: false,
AutoIncr: false,
},
Create generic backend process, fix background interdependencies This refactor was born out of the inter-dependency cycles developing between the "background" module and just about every other module which was caused by the background module becoming a dependency of every module that needed to background work and the fact that the background module was also supposedly responsible for the logic for processing those tasks. Instead the "background" module is now very, very shallow and relies entirely on the Postgres NOTIFY logic for triggering jobs. There's a new table, `job` which holds just a type and single row ID. All told, this means that jobs can be added to the queue as part of the API-level or platform-level transaction, ensuring atomicity, and processing coordination is handled by the platform module, which can depend on anything.
2026-03-16 19:52:29 +00:00
ID: column{
Name: "id",
DBType: "integer",
Default: "IDENTITY",
Comment: "",
Nullable: false,
Generated: true,
AutoIncr: false,
},
Remove old FieldSeeker tables, use v2 generated tables. This requires a bunch of changes since the types on these tables are much closer to the underlying types of the Fieldseeker data we are getting back from the API. I now need to use proper UUID types everywhere, which means I had to modify the bob gen config to consistently use google UUID, my UUID library of choice. I also had to add the organization_id to all the fieldseeker tables since we rely on them existing for some of our compound queries. There were some changes to the API type signatures to get things to build. I may yet regret those.
2025-12-24 17:49:39 -07:00
},
Indexes: noteAudioIndexes{
NoteAudioPkey: index{
Type: "btree",
Name: "note_audio_pkey",
Columns: []indexColumn{
{
Name: "version",
Desc: null.FromCond(false, true),
IsExpression: false,
},
{
Name: "uuid",
Desc: null.FromCond(false, true),
IsExpression: false,
},
},
Unique: true,
Comment: "",
NullsFirst: []bool{false, false},
NullsDistinct: false,
Where: "",
Include: []string{},
},
Create generic backend process, fix background interdependencies This refactor was born out of the inter-dependency cycles developing between the "background" module and just about every other module which was caused by the background module becoming a dependency of every module that needed to background work and the fact that the background module was also supposedly responsible for the logic for processing those tasks. Instead the "background" module is now very, very shallow and relies entirely on the Postgres NOTIFY logic for triggering jobs. There's a new table, `job` which holds just a type and single row ID. All told, this means that jobs can be added to the queue as part of the API-level or platform-level transaction, ensuring atomicity, and processing coordination is handled by the platform module, which can depend on anything.
2026-03-16 19:52:29 +00:00
NoteAudioIDUnique: index{
Type: "btree",
Name: "note_audio_id_unique",
Columns: []indexColumn{
{
Name: "id",
Desc: null.FromCond(false, true),
IsExpression: false,
},
},
Unique: true,
Comment: "",
NullsFirst: []bool{false},
NullsDistinct: false,
Where: "",
Include: []string{},
},
Remove old FieldSeeker tables, use v2 generated tables. This requires a bunch of changes since the types on these tables are much closer to the underlying types of the Fieldseeker data we are getting back from the API. I now need to use proper UUID types everywhere, which means I had to modify the bob gen config to consistently use google UUID, my UUID library of choice. I also had to add the organization_id to all the fieldseeker tables since we rely on them existing for some of our compound queries. There were some changes to the API type signatures to get things to build. I may yet regret those.
2025-12-24 17:49:39 -07:00
},
PrimaryKey: &constraint{
Name: "note_audio_pkey",
Columns: []string{"version", "uuid"},
Comment: "",
},
ForeignKeys: noteAudioForeignKeys{
NoteAudioNoteAudioCreatorIDFkey: foreignKey{
constraint: constraint{
Name: "note_audio.note_audio_creator_id_fkey",
Columns: []string{"creator_id"},
Comment: "",
},
ForeignTable: "user_",
ForeignColumns: []string{"id"},
},
NoteAudioNoteAudioDeletorIDFkey: foreignKey{
constraint: constraint{
Name: "note_audio.note_audio_deletor_id_fkey",
Columns: []string{"deletor_id"},
Comment: "",
},
ForeignTable: "user_",
ForeignColumns: []string{"id"},
},
NoteAudioNoteAudioOrganizationIDFkey: foreignKey{
constraint: constraint{
Name: "note_audio.note_audio_organization_id_fkey",
Columns: []string{"organization_id"},
Comment: "",
},
ForeignTable: "organization",
ForeignColumns: []string{"id"},
},
},
Create generic backend process, fix background interdependencies This refactor was born out of the inter-dependency cycles developing between the "background" module and just about every other module which was caused by the background module becoming a dependency of every module that needed to background work and the fact that the background module was also supposedly responsible for the logic for processing those tasks. Instead the "background" module is now very, very shallow and relies entirely on the Postgres NOTIFY logic for triggering jobs. There's a new table, `job` which holds just a type and single row ID. All told, this means that jobs can be added to the queue as part of the API-level or platform-level transaction, ensuring atomicity, and processing coordination is handled by the platform module, which can depend on anything.
2026-03-16 19:52:29 +00:00
Uniques: noteAudioUniques{
NoteAudioIDUnique: constraint{
Name: "note_audio_id_unique",
Columns: []string{"id"},
Comment: "",
},
},
Remove old FieldSeeker tables, use v2 generated tables. This requires a bunch of changes since the types on these tables are much closer to the underlying types of the Fieldseeker data we are getting back from the API. I now need to use proper UUID types everywhere, which means I had to modify the bob gen config to consistently use google UUID, my UUID library of choice. I also had to add the organization_id to all the fieldseeker tables since we rely on them existing for some of our compound queries. There were some changes to the API type signatures to get things to build. I may yet regret those.
2025-12-24 17:49:39 -07:00
Comment: "",
}
type noteAudioColumns struct {
Created column
CreatorID column
Deleted column
DeletorID column
Duration column
OrganizationID column
Transcription column
TranscriptionUserEdited column
Version column
UUID column
Create generic backend process, fix background interdependencies This refactor was born out of the inter-dependency cycles developing between the "background" module and just about every other module which was caused by the background module becoming a dependency of every module that needed to background work and the fact that the background module was also supposedly responsible for the logic for processing those tasks. Instead the "background" module is now very, very shallow and relies entirely on the Postgres NOTIFY logic for triggering jobs. There's a new table, `job` which holds just a type and single row ID. All told, this means that jobs can be added to the queue as part of the API-level or platform-level transaction, ensuring atomicity, and processing coordination is handled by the platform module, which can depend on anything.
2026-03-16 19:52:29 +00:00
ID column
Remove old FieldSeeker tables, use v2 generated tables. This requires a bunch of changes since the types on these tables are much closer to the underlying types of the Fieldseeker data we are getting back from the API. I now need to use proper UUID types everywhere, which means I had to modify the bob gen config to consistently use google UUID, my UUID library of choice. I also had to add the organization_id to all the fieldseeker tables since we rely on them existing for some of our compound queries. There were some changes to the API type signatures to get things to build. I may yet regret those.
2025-12-24 17:49:39 -07:00
}
func (c noteAudioColumns) AsSlice() []column {
return []column{
Create generic backend process, fix background interdependencies This refactor was born out of the inter-dependency cycles developing between the "background" module and just about every other module which was caused by the background module becoming a dependency of every module that needed to background work and the fact that the background module was also supposedly responsible for the logic for processing those tasks. Instead the "background" module is now very, very shallow and relies entirely on the Postgres NOTIFY logic for triggering jobs. There's a new table, `job` which holds just a type and single row ID. All told, this means that jobs can be added to the queue as part of the API-level or platform-level transaction, ensuring atomicity, and processing coordination is handled by the platform module, which can depend on anything.
2026-03-16 19:52:29 +00:00
c.Created, c.CreatorID, c.Deleted, c.DeletorID, c.Duration, c.OrganizationID, c.Transcription, c.TranscriptionUserEdited, c.Version, c.UUID, c.ID,
Remove old FieldSeeker tables, use v2 generated tables. This requires a bunch of changes since the types on these tables are much closer to the underlying types of the Fieldseeker data we are getting back from the API. I now need to use proper UUID types everywhere, which means I had to modify the bob gen config to consistently use google UUID, my UUID library of choice. I also had to add the organization_id to all the fieldseeker tables since we rely on them existing for some of our compound queries. There were some changes to the API type signatures to get things to build. I may yet regret those.
2025-12-24 17:49:39 -07:00
}
}
type noteAudioIndexes struct {
Create generic backend process, fix background interdependencies This refactor was born out of the inter-dependency cycles developing between the "background" module and just about every other module which was caused by the background module becoming a dependency of every module that needed to background work and the fact that the background module was also supposedly responsible for the logic for processing those tasks. Instead the "background" module is now very, very shallow and relies entirely on the Postgres NOTIFY logic for triggering jobs. There's a new table, `job` which holds just a type and single row ID. All told, this means that jobs can be added to the queue as part of the API-level or platform-level transaction, ensuring atomicity, and processing coordination is handled by the platform module, which can depend on anything.
2026-03-16 19:52:29 +00:00
NoteAudioPkey index
NoteAudioIDUnique index
Remove old FieldSeeker tables, use v2 generated tables. This requires a bunch of changes since the types on these tables are much closer to the underlying types of the Fieldseeker data we are getting back from the API. I now need to use proper UUID types everywhere, which means I had to modify the bob gen config to consistently use google UUID, my UUID library of choice. I also had to add the organization_id to all the fieldseeker tables since we rely on them existing for some of our compound queries. There were some changes to the API type signatures to get things to build. I may yet regret those.
2025-12-24 17:49:39 -07:00
}
func (i noteAudioIndexes) AsSlice() []index {
return []index{
Create generic backend process, fix background interdependencies This refactor was born out of the inter-dependency cycles developing between the "background" module and just about every other module which was caused by the background module becoming a dependency of every module that needed to background work and the fact that the background module was also supposedly responsible for the logic for processing those tasks. Instead the "background" module is now very, very shallow and relies entirely on the Postgres NOTIFY logic for triggering jobs. There's a new table, `job` which holds just a type and single row ID. All told, this means that jobs can be added to the queue as part of the API-level or platform-level transaction, ensuring atomicity, and processing coordination is handled by the platform module, which can depend on anything.
2026-03-16 19:52:29 +00:00
i.NoteAudioPkey, i.NoteAudioIDUnique,
Remove old FieldSeeker tables, use v2 generated tables. This requires a bunch of changes since the types on these tables are much closer to the underlying types of the Fieldseeker data we are getting back from the API. I now need to use proper UUID types everywhere, which means I had to modify the bob gen config to consistently use google UUID, my UUID library of choice. I also had to add the organization_id to all the fieldseeker tables since we rely on them existing for some of our compound queries. There were some changes to the API type signatures to get things to build. I may yet regret those.
2025-12-24 17:49:39 -07:00
}
}
type noteAudioForeignKeys struct {
NoteAudioNoteAudioCreatorIDFkey foreignKey
NoteAudioNoteAudioDeletorIDFkey foreignKey
NoteAudioNoteAudioOrganizationIDFkey foreignKey
}
func (f noteAudioForeignKeys) AsSlice() []foreignKey {
return []foreignKey{
f.NoteAudioNoteAudioCreatorIDFkey, f.NoteAudioNoteAudioDeletorIDFkey, f.NoteAudioNoteAudioOrganizationIDFkey,
}
}
Create generic backend process, fix background interdependencies This refactor was born out of the inter-dependency cycles developing between the "background" module and just about every other module which was caused by the background module becoming a dependency of every module that needed to background work and the fact that the background module was also supposedly responsible for the logic for processing those tasks. Instead the "background" module is now very, very shallow and relies entirely on the Postgres NOTIFY logic for triggering jobs. There's a new table, `job` which holds just a type and single row ID. All told, this means that jobs can be added to the queue as part of the API-level or platform-level transaction, ensuring atomicity, and processing coordination is handled by the platform module, which can depend on anything.
2026-03-16 19:52:29 +00:00
type noteAudioUniques struct {
NoteAudioIDUnique constraint
}
Remove old FieldSeeker tables, use v2 generated tables. This requires a bunch of changes since the types on these tables are much closer to the underlying types of the Fieldseeker data we are getting back from the API. I now need to use proper UUID types everywhere, which means I had to modify the bob gen config to consistently use google UUID, my UUID library of choice. I also had to add the organization_id to all the fieldseeker tables since we rely on them existing for some of our compound queries. There were some changes to the API type signatures to get things to build. I may yet regret those.
2025-12-24 17:49:39 -07:00
func (u noteAudioUniques) AsSlice() []constraint {
Create generic backend process, fix background interdependencies This refactor was born out of the inter-dependency cycles developing between the "background" module and just about every other module which was caused by the background module becoming a dependency of every module that needed to background work and the fact that the background module was also supposedly responsible for the logic for processing those tasks. Instead the "background" module is now very, very shallow and relies entirely on the Postgres NOTIFY logic for triggering jobs. There's a new table, `job` which holds just a type and single row ID. All told, this means that jobs can be added to the queue as part of the API-level or platform-level transaction, ensuring atomicity, and processing coordination is handled by the platform module, which can depend on anything.
2026-03-16 19:52:29 +00:00
return []constraint{
u.NoteAudioIDUnique,
}
Remove old FieldSeeker tables, use v2 generated tables. This requires a bunch of changes since the types on these tables are much closer to the underlying types of the Fieldseeker data we are getting back from the API. I now need to use proper UUID types everywhere, which means I had to modify the bob gen config to consistently use google UUID, my UUID library of choice. I also had to add the organization_id to all the fieldseeker tables since we rely on them existing for some of our compound queries. There were some changes to the API type signatures to get things to build. I may yet regret those.
2025-12-24 17:49:39 -07:00
}
type noteAudioChecks struct{}
func (c noteAudioChecks) AsSlice() []check {
return []check{}
}
Reference in a new issue Copy permalink