Comments (8)
There is no specific support for Auto-Incremental IDs in rest-layer itself. However I belive a resource.Storer
implementation can alter the passed in items (e.g. populate an ID field) on insert operations.
rest-layer/resource/storage.go
Line 10 in 0fa67ca
The SQL/Postgre SQL storer backend is thirdparty, and not maintained by us. It's probably best to start the implementation of such a feature there.
Otherwise, be sure to understand the limitations of auto incremental IDs, and when (not) to use them:
- Easy to guess (sometimes a security concern)
- Reveal information about number of items (sometimes a security concern)
- Finite (Eventually you may run out of IDs)
- Not distributed (Won't easily scale to multiple databases)
If you don't have a specific use-case where Auto-Incremental IDs are essential, I would at least personal recommend against using them.
from rest-layer.
I don't have control over the schema to change the ID
from auto increment to uuid
.
However, I wasn't looking for Auto-Incremental ID support in rest-layer, instead what I was looking for is a way to specify exclusion of the ID
field when creating/inserting objects through POST request.
I was thinking of forking the repo, adding the functionality of field exclusion from POST requests only.
Then I will use it for my use case and create a PR for the same, so that if you are happy with the changes, then maybe rest-layer
can support it.
Can you point me to the right direction for the same?
from rest-layer.
The SQL backend I know about is here:
A good starting point may be to fork that and start trying out different things.
You can start experimenting with saving an item without an ID, and see where it fails using the resource
layer directly.
If it fails in the storage backend, then that would be a good place to try to implement AutoIncremental ID support. If it fails in rest-layer, we can look at what changes are needed to allow for an empty ID.
An alternative to an empty ID, could also to define a "dummy" value (in the OnOnit field hook), that the storer backend ignores or translates into a relevant. Such a field-type could be defined in the storer backend.
from rest-layer.
I was running out of time and needed to show something, so I hacked my way to using auto incrementing integers with https://github.com/apuigsech/rest-layer-sql
I am now able to make POST requests and rows are getting created in the DB, however I am facing a more fundamental problem.
If I make a GET request to this path /api/users/4
I am getting this error:
{
"code": 500,
"message": "not an integer"
}
I tracked the problem and found this:
We assume the ID
to be string here
Line 97 in 0fa67ca
Then we try to validate the
ID
with the field ID here rest-layer/rest/resource_path.go
Line 57 in 0fa67ca
id
as string and not int.
I have noticed two assumptions (correct me if I am wrong):
a) ID is a string
b) ID is randomly generated ID and not database generated
For my use case I need these two features supported:
a) ID can be integer and not just string
b) Support for fields whose values are generated at the DB level.
I understand the fact that this requires changes in Storer interface
rest-layer/resource/storage.go
Line 10 in 0fa67ca
I understand that these are fundamental changes and would require lot of effort and careful considerations.
I was hoping to use rest-layer in production but because of my restrictions of not being able to change the schema it doesn't looks feasible to use it right now.
Having said that, I am more than willing and happy to contribute and make all the changes required to support the above mentioned features. However, I will need your help and guidance to get this done.
I am hoping that if you agree and we work to get these features supported, then I will be able to use it in my production.
from rest-layer.
a) ID is a string.
ID is always a string when read from the URL as opposed to read from JSON, where it can have different types. To fix this, you can try to let the ID field validator support a "string" input and convert it to an integer (basically write your own FieldValidator). After an ID is parsed, there should be no further assumptions requiring the ID to be a string.
b) ID is randomly generated ID and not database generated.
There is no assumption that it is generated. However, it's possible that there could be some places where it's assumed that the ID field is set before the resource.Item reaches the storer backend (even when the field is not set as Required
) -- you just need to check that ( I don't remember all parts of the code good enough to give a definitive answer). If you are able to do a POST as you describe, then it's a good indication that not having an ID is actually allowed.
Either way there should be no need of changing the Storer interface to support this. the storer interface is passed pointers to resource.Items
, and if these items don't contain an ID during an Insert
operation then just set one. It should be encoded back into the response if it's set.
from rest-layer.
There indeed are places where it is assumed that ID field is set as you have already pointed in b).
Right now I am doing these:
a) Using a dirty hack of fetching the max ID from database in the OnInit
function.
b) Forked rest-layer-sql
and
i) added support for filtering on integer fields
ii) converting int64 to int while setting item.ID
This setup gets me going.
Going forward, I will create PRs for both rest-layer
and rest-layer-sql
to add support for ID
to be integer and database generated fields.
Thanks for all the help that you have provided.
P.S.: If you wish we can close this issue and open another one once I have created the PRs and/or need help. Alternatively we can label this issue appropriately to indicate that initial issues are resolved and more work is expected in future.
from rest-layer.
Here is a possible less hacky approach you can try (add this field definition to your rest-layer-sql
fork). PS! Haven't looked up all the definitions, so the code below is liekely to contain errors. Check the docs to adapt/complete it.
type autoIncrType uint8
const (
AutoIncr autoIncrType = iota // Dummy value set in rest-layer that we can detect in the backend.
)
type AutoIncrInt64Field = schema.Field{
Required: true,
Oninit: func() {return AutoIncr},
FieldValidatior: &AutoIncrInt64Validator{},
}
type AutoIncrValidator struct{}
func (*AutoIncrValidator) Validate(v interface{}) (out interface{}, error) {
var i int64
switch vt := v.(type) {
case autoIncrType {
// Let SQL backend detect and remove this..
return v, nil
case string:
i = ... // parse vt to int64
case int64:
i = vt
case int32:
i = int64(vt)
default:
return nil, ErrNotAnIntger
}
return i, nil
}
You can imagine a similar type for int32
or other integer type if relevant.
from rest-layer.
Let's keep it open for now @ishan1608, and you can keep asking your questions here. Relabeled renamed it.
from rest-layer.
Related Issues (20)
- Validate fields depending on other field values HOT 2
- Remove old sub-resource syntax HOT 4
- go module: cannot find module providing package testing/mem HOT 3
- Explicit $eq in filter passes whole predicate to Validate(Query) HOT 3
- OnInsert/OnUpdate hooks can modify the new resource item, Etag not recalculated HOT 7
- `Prefer: return=minimal` can hide resource item on server modification HOT 12
- Consistent empty / null fields HOT 4
- Remove resource hooks in favor of resource middleware HOT 12
- Newest `zerolog` versions cause a panic HOT 4
- Bogus error line, when returning empty response on 204
- Etag should not depend on external state HOT 4
- How use schema and resource package as standalone HOT 1
- Bulk PATCH support HOT 5
- Wrapping original issue in rest.Error HOT 7
- Feature Request: Cursor-based Pagination HOT 3
- pq: operator does not exist: uuid ~~ unknown HOT 7
- Filter on reference fields HOT 1
- Support for $not filter operation HOT 4
- Decouple ElemMatch from schema.Array struct
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rest-layer.