Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add auto increment field for non database formats #18721

Open
qgib opened this issue May 17, 2014 · 5 comments
Open

Add auto increment field for non database formats #18721

qgib opened this issue May 17, 2014 · 5 comments
Labels
Feature Request Vectors Related to general vector layer handling (not specific data formats)

Comments

@qgib
Copy link
Contributor

qgib commented May 17, 2014

Author Name: Paolo Cavallini (@pcav)
Original Redmine Issue: 10295

Redmine category:vectors


It would be usefull to add a QGIS Field edittype called "Serial" and implementing auto-incrementation for non-database formats :

  • in the form, make the field visible but not editable
  • for new object, get the next number

QGIS could store the current serial state in the project file and update it during the commit, and manage multiple inserts and errors on insert

@qgib
Copy link
Contributor Author

qgib commented Sep 16, 2016

Author Name: gcarrillo - (gcarrillo -)


The AutoFields plugin [1] helps you achieve almost all you mentioned, except making the field non-editable.
Watch this video of an automatic id field for Shapefiles (and any other editable vector layer in QGIS).

Please give it a try. If it works for you, we could close this issue.

--
[1] http://plugins.qgis.org/plugins/AutoFields/
[2] https://vimeo.com/178923847

@qgib
Copy link
Contributor Author

qgib commented Apr 30, 2017

Author Name: Giovanni Manghi (@gioman)


  • easy_fix was configured as 0

@qgib
Copy link
Contributor Author

qgib commented Feb 24, 2018

Author Name: Paolo Cavallini (@pcav)


Sounds good. IMHO this should be promoted to a core function, and in any case the plugin should be ported to QGIS 3 before closing this ticket.


  • description was changed from It would be usefull to add a QGIS Field edittype called "Serial" and implementing auto-incrementation for non-database formats :
  • in the form, make the field visible but not editable
  • for new object, get the next number

QGIS could store the current serial state in the project file and update it during the commit, and manage multiple inserts and errors on insert to It would be usefull to add a QGIS Field edittype called "Serial" and implementing auto-incrementation for non-database formats :

  • in the form, make the field visible but not editable
  • for new object, get the next number

QGIS could store the current serial state in the project file and update it during the commit, and manage multiple inserts and errors on insert

@qgib
Copy link
Contributor Author

qgib commented Feb 24, 2018

Author Name: Giovanni Manghi (@gioman)


Paolo Cavallini wrote:

Sounds good. IMHO this should be promoted to a core function, and in any case the plugin should be ported to QGIS 3 before closing this ticket.

creating a gpkg in qgis adds an autoincrementing fid field.

@qgib qgib added Feature Request Vectors Related to general vector layer handling (not specific data formats) labels May 25, 2019
@antoniolocandro
Copy link
Contributor

I would think having an option to do this should be possible, virtual fields work if you set it to $id for the most part so I guess the implementation should be possible. In the case of shapefile by default QGIS already includes a field named id and of type integer so having the option to be $id (auto increment) seems logical.

Also I am sorry to say that even though GPKG is a good format many people have a constrain on which format they are able to use based on clients or agency decision

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Request Vectors Related to general vector layer handling (not specific data formats)
Projects
None yet
Development

No branches or pull requests

2 participants