PacketFence - BTS - PacketFence
View Issue Details
0000914PacketFencerefactoringpublic2010-02-17 17:162011-01-26 15:42
obilodeau 
obilodeau 
highminorN/A
closedfixed 
 
2.0.02.0.0 
8116f6f5657fa9232ce57c50c926e66f23abe079
0000914: node table should not carry data duplicated from locationlog
Right now, the node table is updated by locationlog_synchronize, pfsetvlan and other mechanism to make sure that port, switch, connection_type and voip are accurate with the latest entry in locationlog.

We should forget about that and join the two tables on node_view_all or a new sub.

This would cleanup a lot of the cruft.
No tags attached.
related to 0000977closed obilodeau VLAN field in node table should be re-thought 
related to 0001082closed  Specify a VLAN per node 
Issue History
2010-02-17 17:16obilodeauNew Issue
2010-02-17 17:16obilodeauStatusnew => assigned
2010-02-17 17:16obilodeauAssigned To => obilodeau
2010-02-17 17:27obilodeauNote Added: 0001471
2010-04-15 17:43obilodeauProjectPacketFence 1.9 => PacketFence
2010-05-04 16:49obilodeauRelationship addedrelated to 0000977
2010-05-05 09:28obilodeauNote Added: 0001543
2010-05-05 09:28obilodeauTarget Version1.9.0 => 1.10.0
2010-09-29 17:04obilodeauRelationship addedrelated to 0001082
2010-09-30 19:00obilodeaumtn revision => 8116f6f5657fa9232ce57c50c926e66f23abe079
2010-09-30 19:00obilodeauNote Added: 0001705
2010-09-30 19:00obilodeauStatusassigned => resolved
2010-09-30 19:00obilodeauFixed in Version => trunk
2010-09-30 19:00obilodeauResolutionopen => fixed
2010-11-19 14:25obilodeauTarget Version1.10.0 => 2.0.0
2010-12-15 11:37obilodeauFixed in Versiontrunk => 2.0.0
2011-01-26 15:42obilodeauStatusresolved => closed

Notes
(0001471)
obilodeau   
2010-02-17 17:27   
It's a tricky one with the SQL but start from:

select * from node join locationlog USING (mac) WHERE mac ='00:11:25:14:15:45' order by start_time desc limit 1;

remember that entries in locationlog also tend to overlap. in ex:
mac               | switch       | port  | vlan | voip | connection_type       | start_time          
| end_time
00:11:25:14:15:45 | 192.168.1.61 | 10003 | 1    | no   | SNMP-Traps            | 2010-02-15 11:15:15 
| NULL
00:11:25:14:15:45 | 192.168.1.61 | 10003 | 2    | no   | SNMP-Traps            | 2010-02-15 11:15:15 
| 2010-02-15 11:15:15


So i'll need to be careful and favor when end_time NULL over latest start_time.
(0001543)
obilodeau   
2010-05-05 09:28   
re-targeted for next feature release
(0001705)
obilodeau   
2010-09-30 19:00   
This change was tackled in the path to fix 0001002.