Setting `id_property` type

[Joshfindit]

Ran across an issue transitioning away from UUID (makes import/export easier, especially for example in the case of Epoch seconds since there is only one 1490146334)

Went from UUID and name to dropping UUID and going with id_property :name, but ran across this totally expected problem:

> AbsoluteUnixMilliSecond.first

Neo.ClientError.Statement.TypeError: Don't know how to compare that. Left: "1490146334.532" (String); Right: 1.49014559657E9 (Double)

What I'd like to do

Found the syntax in the repo

class AbsoluteUnixTime
  include Neo4j::ActiveNode
  id_property :name
  id_property_type: String

class AbsoluteUnixSecond < AbsoluteUnixTime
  include Neo4j::ActiveNode
  id_property :name
  id_property_type: Integer
  ...
end

What happens when I do it

id_property_type: Integer

syntax error, unexpected ':', expecting keyword_end (SyntaxError)
  id_property_type: String

or id_property_type String

 undefined method `id_property_type' for AbsoluteUnixTime(name: Object):Class (NoMethodError)
Did you mean?  id_property_name
               id_property_info

Runtime information:

Neo4j database version: neo4j gem version: 8.0.9 neo4j-core gem version: 7.0.6

[cheerfulstoic]

I don't think it's currently possible to define the type for an id_property. This line is where id_property defines the underlying property, but as you can see it just passes in one argument.

Honestly, the way id_property is implemented has bugged me for a while. Really we should probably be defining a property and passing in an option to specify that it's the ID (or perhaps better yet, defining a property and then simply calling id_property to say that that property is the ID property)

[Joshfindit]

When I went to define it, that was what felt natural: define the property then tell neo4jrb that the defined property was the id.

Is it feasible to suggest allowing id_property to take either the current inputs or an already-defined property?

On May 28, 2017, at 7:16 PM, Brian Underwood [email protected] wrote:

I don't think it's currently possible to define the type for an id_property. This line is where id_property defines the underlying property, but as you can see it just passes in one argument.

Honestly, the way id_property is implemented has bugged me for a while. Really we should probably be defining a property and passing in an option to specify that it's the ID (or perhaps better yet, defining a property and then simply calling id_property to say that that property is the ID property)

― You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[cheerfulstoic]

Yeah, what you did makes sense with the way that id_property is defined, but I don't like the way that id_property is defined ;)

Obviously both ways are feasible. The current way would be easier to modify, the way I'm suggesting would take longer but would be a better (I think) longer term solution for the gem (though, of course, there would need to be backwards compatibility for a while)

[Joshfindit]

Any thoughts on this lately?

I'm coming back to wanting to use Unix Epoch Milliseconds as node names since they don't need a UUID to be uniquely identified.

[cheerfulstoic]

Thinking about this again I think it would be totally fine to define the new way of doing things (define property and have the id_property method specify which one it is). The id_property method could then check to see if the property is defined and, if not, give a deprecation warning (but still just define the property under the covers).

Actually, this would also potentially help with another long standing thing: Some people have asked for the ability to define their own uuid in the new / create / property= methods. If we defined the ID as just another property but which is tagged separately as special, then the implementation would probably be simpler and a bit more flexible.

But to your original problem, I'm not sure why you couldn't use a timestamp as your id_property. When you call first it's doing an ORDER BY node.your_id_property, so does your database maybe have some of those as integers and some as strings? If you had a migration so that they were all the same type of value it might work (unless I'm misunderstanding)

[mvitale]

Years later I'm running into the same issue (not being able to set a type for the id_property). Since it's been so long I figured I'd ask if anything has changed in newer versions. Thanks!

[seuros]

@mvitale
the code bellow auto detect type, you will have to set id before you create a node

id_property :country_code

this will set a uuid

id_property :user_id, auto: :uuid