Giter Site home page Giter Site logo

django-macaddress's Introduction

django-macaddress

Build Status

MAC Address model and form fields for Django

We use netaddr to parse and validate the MAC address. The tests aren't complete yet.

Patches welcome: http://github.com/django-macaddress/django-macaddress

Release Notes:

For release info: https://github.com/django-macaddress/django-macaddress/releases

Getting Started

settings.MACADDRESS_DEFAULT_DIALECT

To specify a default dialect for presentation (and storage, see below), specify:

settings.MACADDRESS_DEFAULT_DIALECT = 'module.dialect_class'

where the specified value is a string composed of a parent python module name and the child dialect class name. For example:

settings.MACADDRESS_DEFAULT_DIALECT = 'netaddr.mac_eui48'

PS: old default of macaddress.mac_linux (uppercase and divided by ':' ) will be used by default.

If the custom dialect is defined in a package module, you will need to define the class in or import into the package's __init__.py.

default_dialect and format_mac

To get the default dialect for your project, import and call the default_dialect function:

>>> from macaddress import default_dialect

>>> dialect = default_dialect()

This function may, optionally, be called with an netaddr.EUI class instance as its argument. If no default is defined in settings, it will return the dialect of the provided EUI object.

The format_mac function takes an EUI instance and a dialect class (netaddr.mac_eui48 or a subclass) as its arguments. The dialect class may be specified as a string in the same manner as settings.MACADDRESS_DEFAULT_DIALECT:

>>> from netaddr import EUI, mac_bare
>>> from macaddress import format_mac

>>> mac = EUI('00:12:3c:37:64:8f')
>>> format_mac(mac, mac_bare)
'00123C37648F'
>>> format_mac(mac, 'netaddr.mac_cisco')
'0012.3c37.648f'

MACAddressField (ModelField)

This is an example model using MACAddressField:

from macaddress.fields import MACAddressField

class Computer(models.Model):
    name = models.CharField(max_length=32)
    eth0 = MACAddressField(null=True, blank=True)
    ...

The default behavior is to store the MAC Address in the database is a BigInteger. If you would, rather, store the value as a string (to, for instance, facilitate sub-string searches), you can specify integer=False and the value will be stored as a string:

class Computer(models.Model):
    name = models.CharField(max_length=32)
    eth0 = MACAddressField(blank=True, integer=False)
    ...

If you want to set unique=True on a MACAddressField that is stored as a string, you will need to set null=True and create custom clean_<foo> methods on your forms.ModelForm class for each MACAddressField that return None when the value provided is an '' (empty string):

from .models import Computer

class ComputerForm(forms.ModelForm):
    class Meta:
        model = Computer

    def clean_eth0(self):
        return self.cleaned_data['eth0'] or None

You should avoid changing the value of integer after running managy.py syncdb, unless you are using a schema migration solution like South or Django's built-in migrations.

To Do

  • Add greater support for partial string queries when storing MACs as strings in the database.
  • Add custom validator to check for duplicate MACs when mixing string and integer storage types.
  • Add deprecation warning and timeline for changeover to default string storage.

django-macaddress's People

Contributors

angvp avatar barszczmm avatar bltravis avatar crtg avatar djailla avatar hugovk avatar jansegre avatar jathanism avatar jimfunk avatar kra3 avatar lociii avatar matjazd avatar movermeyer avatar pranaysharma avatar pyup-bot avatar sumpfralle avatar ten0 avatar timgates42 avatar tubaman avatar uxio0 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

django-macaddress's Issues

changed mac dividning char from : to -

Since the update to 1.1.0 the mac address representation is no longer 00:11:22:33:44:55 but 00-11-22-33-44-55 which caused my app to crash.... so had to roll back to 1.0.1 ....

Storage and display format is different

When no MACADDRESS_DEFAULT_DIALECT is specified, addresses are stored in the format 00-00-00-00-12-89 but displayed in the format 00:00:00:00:12:89. Why is there a difference in storage and display format?

reopen #7

see my remark in issue #7
I could not find the reopen option (probably only you can)

and sorry for introducing this bug... I was mistaken in the name to lookup the package info...

Initial Update

The bot created this issue to inform you that pyup.io has been set up on this repo.
Once you have closed it, the bot will open pull requests for updates as soon as they are available.

documentation old style notation

First: Great improvements in 1.3.0 !

Can you add to the documentation the following:

To get the old known macaddress notation, use (uppercase and divided by ':' ) in settings.py:

MACADDRESS_DEFAULT_DIALECT = 'macaddress.mac_linux'

Please add tests to pypi package

For downstream it would be great if the tests are also bundled in the pypi package, so that OS package maintainers can include testing in their release cycle.

Search in admin doesn't work

Today, I've noticed that search for mac address in admin doesn't work.

Reason being, mac address is stored as a BigInteger by the MACAddressField and search algorithm in django doesn't know that internal format used by mac address is different.

Do you see any fix for this issue (only way I see is that the data should be stored as is in a Charfield and not as a BigInteger)

Also, it'd be nice if we can use macaddr type if DB is Postgre SQL.

lowercase / uppercase inconsistency

class Host(models.Model):
    mac = MACAddressField()
    ip = models.GenericIPAddressField()
> h = Host(mac='11:22:33:aa:bb:cc', ip='192.168.0.1')
> h.save()
> print(h.mac)

'11:22:33:aa:bb:cc'

> h2 = Host.objects.all()[0]
> print(h2.mac)

'11:22:33:AA:BB:CC'

Version visibility for django debug toolbar

I work with django debug toolbar.

I noticed it is very easy to have the version of your app vissible for django debug toolbar (and other tools)

If you put the variable in setup.py:

version = "1.2.0"

and for maintainablilty it is easier to use this version also further on in your setup.py config:

setup(
    name = "django-macaddress",
    version = version,
..

and put this in your

./macaddress/__init__.py

file:

# package
import pkg_resources

__version__ = pkg_resources.get_distribution("macaddress").version
VERSION = __version__  # synonym

your version is visible for several purpuses (also django-debug-toolbar)

mac always a string under python3

Under python3 I see the following although I have set MACADDRESS_DEFAULT_DIALECT = 'netaddr.mac_eui48'

In [1]: from infrabrowser.models import Unit
In [2]: Unit.objects.first().mac
Out[2]: '207369326246'

Following patch (suggested by 2to3) fixes this issue

--- /usr/local/lib/python2.7/site-packages/macaddress/fields.py (original)
+++ /usr/local/lib/python2.7/site-packages/macaddress/fields.py (refactored)
@@ -9,10 +9,9 @@

 import warnings

-class MACAddressField(models.Field):
+class MACAddressField(models.Field, metaclass=models.SubfieldBase):
     description = "A MAC address validated by netaddr.EUI"
     empty_strings_allowed = False
-    __metaclass__ = models.SubfieldBase
     dialect = None

     def __init__(self, *args, **kwargs):

Pytest warning: Remove the context parameter from MACAddressField.from_db_value()

Hi there,

We're seeing these warnings when running pytest:

/usr/local/lib/python3.6/site-packages/django/db/models/sql/compiler.py:995: RemovedInDjango30Warning: Remove the context parameter from MACAddressField.from_db_value(). Support for it will be removed in Django 3.0.

Environment:

Django>=2.1,<2.2
pytest
pytest-cov
pytest-django

Best, Simon.

Django 1.9 compatibility

Using your module with Django 1.8 I had the following warning:

formfields.py:1: RemovedInDjango19Warning: The django.forms.util module has been renamed. Use django.forms.utils instead.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.