intranet caffeine manager slots and caffeine interface have diverged

[colegleason]

Slots counts seem to be incorrect. Are they reading the same tables?

[colegleason]

cc @ace-n

[ace-n]

This would be a question for @CJS7070 since he handled the push to prod and
DB setup. I know the money amounts synced, but I don't remember if we
tested soda counts or not.
On Sep 23, 2014 1:44 PM, "Cole Gleason" [email protected] wrote:

Slots counts seem to be incorrect. Are they reading the same tables?

—
Reply to this email directly or view it on GitHub
#268.

[colegleason]

@ace-n Well I'm wondering if the machine counts were actually changed on the caffeine project to read from the acm_integrate DB.

[ace-n]

That sounds logical. I'm more suspecting of Caffeine than Liquid if the
problem is basically counts not updating on vends (I should test this later
today?)

On Sep 23, 2014 1:54 PM, "Cole Gleason" [email protected] wrote:

@ace-n Well I'm wondering if the machine counts were actually changed on
the caffeine project to read from the acm_integrate DB.

—
Reply to this email directly or view it on GitHub.

[colegleason]

@ace-n When you migrated the counts from the old tables to the new one interface, did you update the caffeine DB setting?

[calvin-shirley]

@ajmadsen can speak to a lot of this.

[colegleason]

@ajmadsen @ace-n Can you look into this? After loading caffeine it is annoying to edit the counts in the DB.

[ace-n]

Yeah - based on the wrong soda names in some of the trays, it seems to me
like they aren't synced. (Cole and I also tried editing things via Liquid,
but changes don't sync in that direction either.)

[ajmadsen]

Liquid doesn't write to the right database/tables. I tried changing Caffeine to match what Liquid's modifying, but it wasn't trivial and wasn't working, so I gave up.

The models in Liquid should be modified to match the existing schema.

[ace-n]

@ajmadsen Are the database names not just in a .conf file?

If we can change it to point at the Liquid DB and modify Liquid's schema,
that would be a decent short term solution. (The long term one would be to
have Caffeine use its own DB and have Liquid point to it, since we intend
to replace Liquid with a less monolithic API-based solution. But I'd
personally rather have this bandaged now and formally fixed later.)

Liquid doesn't write to the right database/tables. I tried changing
Caffeine to match what Liquid's modifying, but it wasn't trivial and wasn't
working, so I gave up.

The models in Liquid should be modified to match the existing schema.

—
Reply to this email directly or view it on GitHub
#268 (comment).

[colegleason]

@ace-n Even if the DBs are in a conf file, either Liquid or Caffeine has to modify the table names.

[colegleason]

The best solution is probably to migrate transactions over to DB "soda" and just have liquid read/write to there. That makes the separation pretty clear.

[ace-n]

@colegleason That's definitely doable, but I was trying to shy away from it
since it adds another layer of complexity (DB routers) to Liquid that apply
just for this use case.
On Oct 11, 2014 9:11 PM, "Cole Gleason" [email protected] wrote:

The best solution is probably to migrate transactions over to DB "soda"
and just have liquid read/write to there. That makes the separation pretty
clear.

—
Reply to this email directly or view it on GitHub
#268 (comment).

[colegleason]

Either Liquid has to munge it's model to fit caffeine or the other way around. I would rather the Caffeine project have the clear coupling with the DB and Liquid add it, as Liquid is just a UI.

[calvin-shirley]

I know @ajmadsen was considering a rewrite of the (vending machine) code for Caffeine. I don't know if this is still scoped, though -- it'd be a side project and I know he's pretty busy with Admin stuff now.

[ace-n]

@colegleason That makes sense. We can remove the DB routers if/when
Caffeine is taken out of Liquid.
On Oct 11, 2014 9:43 PM, "Cole Gleason" [email protected] wrote:

Either Liquid has to munge it's model to fit caffeine or the other way
around. I would rather the Caffeine project have the clear coupling with
the DB and Liquid add it, as Liquid is just a UI.

—
Reply to this email directly or view it on GitHub
#268 (comment).

[ajmadsen]

So the databases and tables Caffeine writes to/reads from are in its machine.conf if you have access to read that. You can get the schemas from the database itself. It's going to be infinitely easier to change liquid code to match what Caffeine's running than the other way around.

Re: the rewrite: it's been stalled due to me having more pressing things to work on.

[ace-n]

@ajmadsen Yeah, that's what I'm going forward with. We can worry about a
more decoupled/proper solution once this issue is fixed, so there's no need
to rush. (FYI in case you haven't heard: We decided a while back that
Liquid is getting too big and is going to get split up into separate
API-based apps; thus, moving away from Liquid is the proper way to go
anyways.)

On Sun, Oct 12, 2014 at 12:41 AM, Adam Madsen [email protected]
wrote:

So the databases and tables Caffeine writes to/reads from are in its
machine.conf if you have access to read that. You can get the schemas from
the database itself. It's going to be infinitely easier to change liquid
code to match what Caffeine's running than the other way around.

Re: the rewrite: it's been stalled due to me having more pressing things
to work on.

—
Reply to this email directly or view it on GitHub
#268 (comment).

[ajmadsen]

Yep. Heard about it. Sounds good.

[ace-n]

Bad news: Django seems to not support cross-DB relations - thus I either
have to disable soda votes for now or move the Vending objects over to
the Soda DB.
On Oct 12, 2014 12:56 AM, "Adam Madsen" [email protected] wrote:

Yep. Heard about it. Sounds good.

—
Reply to this email directly or view it on GitHub
#268 (comment).

[ajmadsen]

Doesn’t the votes table also have a foreign key on Uid—from whatever table we hold user info in on acm_integrate?

On Oct 14, 2014, at 5:56 PM, Ace Nassri [email protected] wrote:

Bad news: Django seems to not support cross-DB relations - thus I either
have to disable soda votes for now or move the Vending objects over to
the Soda DB.
On Oct 12, 2014 12:56 AM, "Adam Madsen" [email protected] wrote:

Yep. Heard about it. Sounds good.

—
Reply to this email directly or view it on GitHub
#268 (comment).

—
Reply to this email directly or view it on GitHub #268 (comment).

[ace-n]

It has a foreign key on Soda, which is the kicker. We might be able to
store the soda ID separately though...
On Oct 14, 2014 7:03 PM, "Adam Madsen" [email protected] wrote:

Doesn’t the votes table also have a foreign key on Uid—from whatever table
we hold user info in on acm_integrate?

On Oct 14, 2014, at 5:56 PM, Ace Nassri [email protected]
wrote:

Bad news: Django seems to not support cross-DB relations - thus I either
have to disable soda votes for now or move the Vending objects over to
the Soda DB.
On Oct 12, 2014 12:56 AM, "Adam Madsen" [email protected]
wrote:

Yep. Heard about it. Sounds good.

—
Reply to this email directly or view it on GitHub
#268 (comment).

—
Reply to this email directly or view it on GitHub <
https://github.com/acm-uiuc/liquid/issues/268#issuecomment-59131162>.

—
Reply to this email directly or view it on GitHub
#268 (comment).

[ajmadsen]

If it doesn’t actually have a foreign key tying it to acm_integrate, we should probably move it to the soda db. I think it makes more sense that way if we consider soda votes within the realm of the Caffeine project. No matter where it ends up though, it seems we’ll have a problem with long-term data integrity.

On Oct 14, 2014, at 7:23 PM, Ace Nassri [email protected] wrote:

It has a foreign key on Soda, which is the kicker. We might be able to
store the soda ID separately though...
On Oct 14, 2014 7:03 PM, "Adam Madsen" [email protected] wrote:

Doesn’t the votes table also have a foreign key on Uid—from whatever table
we hold user info in on acm_integrate?

On Oct 14, 2014, at 5:56 PM, Ace Nassri [email protected]
wrote:

Bad news: Django seems to not support cross-DB relations - thus I either
have to disable soda votes for now or move the Vending objects over to
the Soda DB.
On Oct 12, 2014 12:56 AM, "Adam Madsen" [email protected]
wrote:

Yep. Heard about it. Sounds good.

—
Reply to this email directly or view it on GitHub
#268 (comment).

—
Reply to this email directly or view it on GitHub <
https://github.com/acm-uiuc/liquid/issues/268#issuecomment-59131162>.

—
Reply to this email directly or view it on GitHub
#268 (comment).

—
Reply to this email directly or view it on GitHub #268 (comment).

[ace-n]

I believe it has a ForeignKey with the User model, which absolutely must
stay in Liquid.

I think our best option is to move the Vending model to the Soda DB, and
just store a User ID with that as a "Foreign Key". It won't have the
integrity enforcement provided by Django, but it should give us what I want.

[ace-n]

What we* want. =P
On Oct 14, 2014 9:31 PM, "Ace Nassri" [email protected] wrote:

I believe it has a ForeignKey with the User model, which absolutely must
stay in Liquid.

I think our best option is to move the Vending model to the Soda DB, and
just store a User ID with that as a "Foreign Key". It won't have the
integrity enforcement provided by Django, but it should give us what I want.

[ajmadsen]

Right. Sounds reasonable.

On Oct 14, 2014, at 9:32 PM, Ace Nassri [email protected] wrote:

What we* want. =P
On Oct 14, 2014 9:31 PM, "Ace Nassri" [email protected] wrote:

I believe it has a ForeignKey with the User model, which absolutely must
stay in Liquid.

I think our best option is to move the Vending model to the Soda DB, and
just store a User ID with that as a "Foreign Key". It won't have the
integrity enforcement provided by Django, but it should give us what I want.

—
Reply to this email directly or view it on GitHub #268 (comment).

[colegleason]

@ajmadsen, can you update us when FS service accounts work?