Fork me on GitHub

my databases are all distributed, no FK could work 🙂


my biggest issue with FK-s would be that they only guarantee that whatever they point at exists ... it doesn't mean that they are pointing at the correct thing. so you can still mess up and happily live in an illusion whilst still corrupting data.


I would make a distinction between the concept of a foreign key, an the implementations of foreign keys


just because in my mind the concept of foreign key is pretty synonymous with "pointer" or "reference" or "name", which are useful, and I use all the time


(I think all this discussion has been about the implementation and why folks don't like those constraints in the database itself...?)


At least, that's what I was assuming 🙂


if you put fks in the database, the fk information is(if I recall) available in the result set metadata, which means you can use it for generic database navigation code instead of looking at column names and guessing


Yup, and that's why the (experimental) datafy/`nav` code in java.jdbc lets you pass in a :schema option to override the convention -- which you could auto-generate based on DB metadata. But this is why that's still experimental because there's no one size fits all for how FK concepts are implemented in any given app... ¯\(ツ)


Thanks @U04V70XH6 for quickly implementing datafy/nav. I played around a little bit. Passing on :schema works pretty good for me. I think, it would be good to throw an error when table is not found. Right now if I accidentally pass wrong :schema I get the default column value back. Which can be hard to debug.


@U3ZPBUVJ7 It's definitely experimental and everything around :schema is TBD -- it's not part of a released version (and it may not be -- I'm designing a sort of java.jdbc2 that it will be part of).


That sounds great! What are going to be other new features in java.jdbc2 besides datafy and nav?


The goal is for it to be simpler (fewer options) and faster, and provide a more intuitive/idiomatic API. I'm hoping to have auto-qualification of column keys baked in (based on table name, from metadata most likely) as well as the datafication stuff (again, based on metadata if available, else schema fragments -- but with qualified keys).


It's still very much in the "hammock" phase right now with some code sketches sitting in a Git repo on OneDrive 🙂