On Thursday, 3 May 2018 at 23:05:02 UTC, Matthias Klumpp wrote:
On Thursday, 3 May 2018 at 21:28:18 UTC, bauss wrote:
On Thursday, 3 May 2018 at 18:01:07 UTC, Matthias Klumpp wrote:
DiamondMVC looks nice, but I would need PostgreSQL support
for sure.
Therefore, I think there are three options:
1) Extend the DiamondMVC ORM to support missing features
that Hibernated has (maybe make it use ddbc as backend?)
2) Revive Hibernated - contacting Vadim Lopatin would be key
for that, and maybe the project could be maintained in the
dlang-community organization (although there are competing
projects for it...)
3) Find a different D ORM that does the job and expand it to
include missing features.
Yes, I completely agree with PostgreSQL support. It's really
important to me getting that working, as well MSSQL. I was
hoping I could find time this weekend to actually do that.
Would it maybe be easier for you to base on ddbc[1] or another
existing abstraction layer for database abstraction?
Ddbc is pretty neat, and even has support for reading structs
directly from the database.
Perhaps, but it'd have to be a forked version as I don't really
want to depend on something that isn't updated regularly.
ddbc's last commit was a year ago.
I can't seem to find a license for it though?
[1]: https://github.com/buggins/ddbc
Perhaps I will end up having another "optional" dependency to
it as a temporary until I can have a better implementation or
something.
The frontend part of postgresql is almost finished, it's just
having the postgresql driver working properly, which is where
it's frozen right now.
Hmm... Does any public code for that exist already that I could
play around with?
Unfortunately, I have a few more unusual requirements for
Postgres, like:
* UUIDs as primary keys, instead of integers
As far as I remember the implementation of @DbId in Diamond, then
it supports whatever type.
Diamond doesn't care much about what type your primary key is.
I will make sure that's how it function of course, if it
currently doesn't behave like it, but I'm pretty sure it does.
* Ability to register custom datatypes with the ORM (version
numbers in this case, the ORM can view them as text, but the
database has a special type for them)
That could be done with some attribute that lets you handle
columns yourself.
Do you have a good name for it?
I was thinking @DbProxy and then the function would be something
like:
@DbProxy(functionName) string field;
...
auto functionName(RawDbType type)
{
return the new datatype that matches the field with the
@DbProxy attribute.
}
* Obviously the usual ORM stuff, one-to-many, many-to-many,
etc. relations
Yes, relations is one thing I haven't added and I have been
wanting to do it for a while.
I will definitely look into having it added as well.
(Obviously not a must-have list, I added support for custom
datatypes to my ddbc fork as well, because it's not really a
feature many people need)
Well, that's kind of the key to most of the development in
Diamond.
I usually add functionality that isn't widely used and in most
cases people implement it themselves ex. the whole diamond.seo is
not usually something a framework has.
Diamond is a neat project, I played around with it about half a
year ago, but didn't test the ORM part at all back then.
It wasn't that good back then and has improved a lot since, as
well many other parts of Diamond. Over the past half year it has
grown rapidly, both in stability and functionality.
