On Monday, July 21, 2014 8:38:54 AM UTC-7, Jonathan Vanasco wrote:
>
> I agree with what Mike said, but I would just suggest renaming
> "projector_table" to something like "purchased_table" or "inventory_table".
> Everything in "models" is a different model of a projector, so the table
> names are a bit confusing.
> <snip>
>
Short answer:
manufacturer/model tables are projectors, and sources are the video inputs
available for that particular model. The sources table is going to be used
to keep track of what the manufacturer has listed in their documentation
for selecting a particular video source. The projectors_table is persistent
storage use for what projectors that the user can control via networking.
Basic information is some text columns that the end-user can assign for
their own (short) notes, but the model_id field is used so that the text
can be matched with the projector that they have control over.
Longer answer.
Column 1 is PJLink code for selecting that input, the rest of the line is
text.
Example for Eiki model LC/XL200 projector: (Text is from Eiki webpage
control)
11 "RGB (pc analog)"
12 "RGB (Scart)"
13 "RGB (PC Digital)"
Example Hitachi CP-X2514: (Text is from PJLink user manual from Hitachi)
11 "Computer IN 1"
12 "Computer IN 2"
13 "Component"
As noted, different manufacturers may have different text for the same
inputs, so the sources table is just keeping track of the text for the
input source - hopefully text that the end-user does not find too confusing
:)
This is not an inventory program. The part I'm looking to add is basic
projector control to a program that will send some output via a second
computer video output to a projector. One point is that there may be
multiple computers connected to a single projector via multiple inputs
(sources). I was thinking of having manufacturer/model/source tables so the
end-user doesn't have to re-enter the information if they just happen to
have multiple projectors with the same model - as a side possibility, also
having an xml file with this information available that can be imported
into those tables.
When the end-user adds a projector to the program, they can select the
projector by manufacturer (Eiki) -> model (LC/XL200) - then the sources
(video inputs) would be added to the projector class so they can then
select the video source to display. Since using PJLink codes would be
confusing ("What does input 11 select?"), the text pulled from the sources
table would then let them use the familiar text (documented in their
projector user manual - like "RGB (pc analog)" ) to select the source.
An example xml file for importing would look something like:
<projector manufacturer='Eiki'>
<model name='LC/XL200'>
<source pjlink='11'>RGB (PC analog)</source>
<source pjlink='12'>RGB (Scart)</source>
<source pjlink='13'>RGB (PC digital)</source>
</model>
<model name=.'...'>
....
</model>
</projector>
With the importing in mind, there still has to be the option for the
end-user to manually add an entry for projector manufacturer/model/sources
(technical note, with PJLink, I can retrieve the manufacturer name, model
name, and the available sources via the network, just not the text for the
sources).
With that, then Jonathan's suggestion of removing the foreign_key on the
sources table and create a 4th table that keeps track of the
model<->sources constraints.
As for the projectors_table, instead of a foreign_key just use an integer
column as an index into the models_table would be the suggestion?
projector_table = Table(u'projector', metadata,
Column(u'id', Integer, primary_key=True),
Column(u'model_2_source_id', Integer)
)
The way things are looking, looks like I'm going to have multiple selects.
Not an issue, since they will only be used on program startup, not during
normal operations.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
