[Maintain-dev] Bugs 30, 50: IP Address usage incorrect

[Brad Morgan]

You are absolutely correct! So I've added the changes you suggested
and pushed those out, thanks for the heads up. I also gave you credit
for the fix, so your name will be forever immortalized in our SVN
logs. :)

As far as changing the field names: The id field in every table in
Maintain's schema auto increments and is unique, allowing us to
reference said object in other tables (aka foreign keys).

Objects in the zone_range table are mappings of ranges to zones, and
each individual range and zone are identified by their respective id's
(which you can look up in the range and zone tables respectively).
This is important because we want to be able to have ranges belong to
multiple zones or vice-versa.

The id field then references the conceptual object of a range to zone
mapping, not so much the range or zone specifically.

On top of that, I think the original plan was to keep as much of the
schema the same as previous versions of maintain in order to allow for
easy upgrades and whatnot. Switching stuff around can quickly spiral
into foreign key hell. (Or so I'm told)

I don't know if that answers your question or not, maybe I'm just
rambling. :) If I'm making an oversight of some kind absolutely let me
know and I'll fix 'er up.

Anyway, thanks so much for the input and help. Helping fix bugs is
invaluable. :) Also, if you would like to see features or additions
added as well be sure to file feature requests, we are always looking
for ways to improve.

Cheers,

On 10/3/07, Dawn Keenan <dkeenan at uwaterloo.ca> wrote:
> The 'id' field in the zone_range table is being used instead of the
> 'range' field in both modules/maintain_action/maintain_action.php and
> class/htdocs/RangeDataList.php, causing generated links to pull up
> information for the wrong range.
>
> Changing appropriate instances of $row_data['id'] to $row_data['range']
> in both files and adding special cases for Edit and Delete links for
> ranges in maintain_action.php to pick up the correct data field fixes
> the problem, but it may be worth considering changing the field names of
> the zone_range table to make the code more elegant.  I suspect at least
> one member of the development team would prefer sleeker code.
>
> This problem has not been fixed as of the 3.1.4 code I pulled from SVN
> this week.
>
> --
> Dawn Keenan
> Information Systems and Technology, University of Waterloo, Waterloo ON
> _______________________________________________
> maintain-dev mailing list
> maintain-dev at osuosl.org
> http://lists.osuosl.org/mailman/listinfo/maintain-dev
>


-- 
Brad Morgan
(503) 740-7192