Fork me on GitHub
Ramon Rios13:02:23

Hello everyone. I'm having a challenge of migrate a MySQL table for a neo4j database. I looking for some libraries and other stuff, but i would like to know if someone has any background on neo4j and clojure


Getting there.. so far setup a protocal for graph-like data structures, which for now is only implemented for in-memory. Ideally if it suppoted MySQL and neo4j it could be used to do migrations. But it's no where there yet, and also don't have time for it in the near future.

Ramon Rios18:02:54

Folks, i'm using next library for get data from mysql.

Ramon Rios18:02:20

i do not got it right on how put the result-set for get as-unqualified-lower-maps

Ramon Rios18:02:02

I read the documentation but i do not got it how could i do my select getting the keys.

Ramon Rios18:02:45

Found the problem

Ramon Rios18:02:15

i was not putting {:builder-fn rs/as-unqualified-lower-maps} on the map, after reading a lot of the docs


I would strongly encourage you to work with qualified keys in hash maps by default, unless you have a critical reason not to. That's why qualified hash maps are the default.

Ramon Rios12:02:44

On my case, i'll only do a select in one table for do a ETL. And with unqualified keys the data was ready to be added into the new db, wich is neo4j. But thank you anyway for your recommendation.


In general, when you work with qualified keys and pass them into any persistence library, it will strip the namespace portion off anyway (because it just calls name on the keywords) so it's safe to work with them -- and it's easier to work with Spec (and a little more descriptive overall).


@U04V70XH6 Are you still holding the same opinion?


Yes, I've repeated that opinion many times in the past several years 🙂


Normally people will, say, query data from db and convert to system domains. For the system domains, are you also using qualified keywords?


Would be appreciated if you could point me an example of how the thing works. My concern is after reaching the qualified cols from db, I will always immediately convert the data to some system model. I will by default remove the namespaces. For example, given an entity

defrecord user
it is repetitive to repeat in the field : user/password, :user/name etc.


Don't use records for domain objects unless you really need to. Use maps.


You can use the hash maps from the DB internally without converting names. I don't understand why people get so hung up on that.


You want qualified names in general so you can tell what type of :name you have -- is it a :user/name, is it an :account/name or a :server/name or what? Those probably all have different rules and its entirely possible you might end up with a merged map containing several of them.


I'll point out that the common JSON libs all either throw away the namespace qualifier or have an option to do so, which means you can use qualified names all the way up to the edge and then switch to unqualified names when returning data as JSON or calling into a 3rd-party service passing JSON.


Do you now about this syntax: #:user{:name "Sean" :password "secret"} -- that's short for {:user/name "Sean" :user/password "secret"} and you can destructure into simple bindings like this (let [{:user/keys [name password] data] ... name ... password ... ) -- it really isn't repetitive to use qualified names.


> You can use the hash maps from the DB internally without converting names. I don’t understand why people get so hung up on that. I see. You are modeling the domain entities all with qualified names. > possible you might end up with a merged map containing several of them. Right. This one touches me.


@U04V70XH6 What’s your take on using keywords for option maps in function arguments. I notice that next.jdbc has most opts to be simple keywords. And yesterday in another channel sounds malli is moving towards qualified keywords.


It's all about how "contextually unique" a name needs to be: options for a small library have a pretty small context for uniqueness so being unqualified is generally fine there. I'll read that Malli link you posted and may respond in a thread on that post.


Right. And the case here for db is two tables might get merged. Further, the domain entity is across the whole systems so conflicts has a large probability.


Yes. And in Malli's case you're dealing with a DSL full of (often unqualified) keywords so you need to be able to distinguish Malli-specific options from elements of the DSL.


The more complex the domain, the more likely you are to need qualified keywords.

thanks3 1

@ramon.rios The Getting Started guide for next.jdbc has examples of the :builder-fn: -- which I would expect everyone to read when they are... getting started... with next.jdbc 🙂

Ramon Rios20:02:32

Definitely. I need to remember sometimes to read something in my second language not so fast 😅