Re: Postgres and other database interfaces
On Sunday, 25 February 2018 at 20:56:16 UTC, Joe wrote:
On Sunday, 25 February 2018 at 16:31:45 UTC, Denis F wrote:
What are these sacrifices for? I do not like idea that I
should drop some functionality of Postgres for conpatibility
with another RDBMSes. Personally, I like specific databases
because it have nuances of functionality that they provide to
me.
Nobody said or implied anything about dropping Postgres
functionality. If you can, please take a look at the contents
of the Psycopg docs (http://initd.org/psycopg/docs/), the most
popular Python Postgres adapter: after the entries for the
connection and cursor classes, you'll see pyscopg2.extensions,
pyscopg2.extras, psycopg2.pool and more. It even includes
support for the recently added logical replication feature.
pyscopg2 passes request arguments as strings inside of it! This
degrades type safety because in D we have types.
Looks like it is uses C format:
cur.execute("SELECT '%s', %s", (123,456,)) -- first arg expected
as "%s" string
cur.fetchone()
('123', 456)
You're obviously reluctant of having to rewrite dpq2 just to
"play along with the other kids". I can understand that, but
who knows, maybe your design is 90% of what the others
want/have/like
No, sure. dpq2 is too lowlevel for this. Users need transactions,
prepared statements wrappers, etc. But I can't implement it in
dpq2 because these things is depedend from other more high level
implementations.
At least, for dpk2, I clearly see that the wrapper is the best
choice.
Re: Postgres and other database interfaces
On Sunday, 25 February 2018 at 19:29:59 UTC, kdevel wrote: On Sunday, 25 February 2018 at 11:46:26 UTC, Denis F wrote: But it is impossible to convert text :names or '?' into Postgres's "$1": Postgres isn't knows fields names at start of a query processing and you can't replace '?' to "$" by simple 'replace' call - it will need full syntax parsing of Posgres SQL query because queries can contain EXECUTE statement (whose purpose is executing dynamic commands). You don't have to parse the full syntax. You must if you want to make a replacement correctly for all types of statements. Quote from another language (which also supports underscore in integer literals): "This language" just drops off supporting of dynamic commands by using prepared statements for requests with arguments: "WARNING: DBD::Pg now (as of version 1.40) uses true prepared statements by sending them to the backend to be prepared by the Postgres server. Statements that were legal before may no longer work." It is trivial to replace any placeholders if you use only prepared statements, yes. But if you after that try to call procedure which calls EXECUTE IMMEDIATE command inside it will fail! How many of your users will understand why this happens? Also I see too high level of abstraction in DBD::Pg. I am isn't add prepared statement wrappers into dpq2 because its implementation depends from async queries handling implementation. dpq2 is "middle-level" - C calls and classes wrappers over some of it.
Re: Postgres and other database interfaces
On Sunday, 25 February 2018 at 15:34:00 UTC, Joe wrote: On Sunday, 25 February 2018 at 09:07:34 UTC, Denis F wrote: Libraries already are similar automatically because RDBMSes uses similar principles. But it is impossible to make libraries absolutely identical due to the presence of important significant nuances in each engine. I don't see how making libraries compatible with each other, i.e., complying with some standard, will result in losing functionality. What I'm talking about is standardizing the names of certain classes and their methods, exceptions, and perhaps some datatypes and the expected order of certain arguments. For example, instead of having classes named Database (sqlite3), PGConnection (ddb) and Connection (dpq2, mysql-native) there's just one name, and that class is expected to have certain methods. I guess this is problem too: sqlite isn't connects at all, and its struct represents RDBMS itself. But other should represent only connections because they manipulate the connection and not controls its server, and connection is a potential source of connection-related exceptions. This is a subtle but important difference too. The library implementor can add others. For example, I see mysql-native has a connection pool and that doesn't need to be part of the standard. Also, some methods can be specified as being optional by the standard, e.g., something like callproc, because not all DBMSs support procedures. This is another confirmation is that there are more differences than similarities between databases. :-) Ok, I propose to be consistent and ask for compliance with the Standard from the RDBMSes. For example, arguments substitution: MySQL uses the '?' PostgreSQL uses $1 SQLite accepts both Oracle uses a :name (Really, it is very important to come to an agreement here because, for sure, the next obvious step is writing an ORM generator on top of the idea what you are proposing.) In PEP 249, this was left up to the implementors (see the paramstyle global), but a footnote suggests that some styles are supposed to be preferred over others. For example, I would not change unobvious at first sight system of classes "Result" and inherited from it class "Answer" for the sake of similarity to other libraries. Simply because this is the way what Postgres client library works, and if this classes will be removed some significant functionality will be lost. I'm sure that in other libraries there is something similar. I'm not sure I understand your example, but perhaps this is getting too specific and close to the discussions that would need to take place betweeen existing implementors. There has to be a negotiation process for a standard to be developed. In my example above, suppose the sqlite3 library developer says "I don't want to have a class named Connection, because my users don't connect to a server". It will be up to the other developers to convince him or to arrive at some compromise What are these sacrifices for? I do not like idea that I should drop some functionality of Postgres for conpatibility with another RDBMSes. Personally, I like specific databases because it have nuances of functionality that they provide to me. And those who wish to "crossbreeding a hedgehog with a snake", at first, can try to write a wrapper around existing SQL libraries. This is faster and more humane in relation to the developers.
Re: Postgres and other database interfaces
On Sunday, 25 February 2018 at 12:12:58 UTC, rikki cattermole wrote: Let's not go inventing a solution here, what does JDBC and ADO.net do? JDBC isn't touches this - it is just passes statement "as is". I.e. it isn't drops support of any type of args.
Re: Postgres and other database interfaces
On Sunday, 25 February 2018 at 09:23:18 UTC, rikki cattermole wrote: It's the same concept as the SQL (and other) Standards. Ok, I propose to be consistent and ask for compliance with the Standard from the RDBMSes. For example, arguments substitution: MySQL uses the '?' PostgreSQL uses $1 SQLite accepts both Oracle uses a :name (Really, it is very important to come to an agreement here because, for sure, the next obvious step is writing an ORM generator on top of the idea what you are proposing.) On IRC earlier today we discussed database libs a bit, we agreed that both "?" and "@name" needed to be supported. No other suggestions came up. We don't really need a third or fourth form I think. ...And you are planned to give up "$1" support in favor of '?' and ":name"? But it is impossible to convert text :names or '?' into Postgres's "$1": Postgres isn't knows fields names at start of a query processing and you can't replace '?' to "$" by simple 'replace' call - it will need full syntax parsing of Posgres SQL query because queries can contain EXECUTE statement (whose purpose is executing dynamic commands).
Re: Postgres and other database interfaces
On Sunday, 25 February 2018 at 03:03:05 UTC, Joe wrote: On Saturday, 24 February 2018 at 23:04:39 UTC, Denis F wrote: If anyone really want to impliment your idea, at my first glance at the PEP 249 I had a feeling that this is work for time less than a 1-2 weeks. It can be a simple wrapper over dpq2, mysql-native, sqlite3, etc. I'm not saying that anyone should implement something like PEP 249, particularly *not* as a wrapper over those libraries. My point is that if the implementors of dpq2, mysql-native, etc., could "get together" (at DConf, in forums, by email) and discuss their interfaces, perhaps they could agree on a set of D database interface classes and then each would work towards that common set. Libraries already are similar automatically because RDBMSes uses similar principles. But it is impossible to make libraries absolutely identical due to the presence of important significant nuances in each engine. That's more or less what the Python DB-SIG did. Then every library would benefit because, for one, the common set can be documented just once. Also, if it's a sufficiently reasonable spec, the libraries that don't move towards it should see less adoption because, unless the divergent library has a significantly enhanced interface, developers will shy away from having to learn a different one. It's the same concept as the SQL (and other) Standards. Ok, I propose to be consistent and ask for compliance with the Standard from the RDBMSes. For example, arguments substitution: MySQL uses the '?' PostgreSQL uses $1 SQLite accepts both Oracle uses a :name (Really, it is very important to come to an agreement here because, for sure, the next obvious step is writing an ORM generator on top of the idea what you are proposing.) There may be variances between implementations but no one has implemented a RETRIEVE or PROJECT statement in lieu of a SELECT statement (and note there *were* relational systems that used the former). For example, I would not change unobvious at first sight system of classes "Result" and inherited from it class "Answer" for the sake of similarity to other libraries. Simply because this is the way what Postgres client library works, and if this classes will be removed some significant functionality will be lost. I'm sure that in other libraries there is something similar.
Re: Postgres and other database interfaces
On Sunday, 25 February 2018 at 03:20:08 UTC, Seb wrote: If you talk about using Travis to build the documentation and push to gh-pages like e.g explained here [1]. There are solutions: a) Use branch protection (GH offers this. No one can force push something to protected branches) b) Use a dedicated bot account (if you are worried about leaking the credentials) c) Use a dedicated *-docs repo to which Travis pushes d) Push to a different location (e.g. S3, netlify ... [1] https://forum.dlang.org/post/tkcndtapfypabsncx...@forum.dlang.org Thank! I will try to solve this
Re: Postgres and other database interfaces
On Saturday, 24 February 2018 at 22:24:58 UTC, bachmeier wrote: On Saturday, 24 February 2018 at 18:41:21 UTC, Denis F wrote: Hi! Here is dpq2 and vibe-d-postgresql developer. The problem is that I do not know English very well. So,I think it's better not to write any documentation than to write the wrong one. There are still some steps you can take: 1. Put a statement on the project page encouraging people to create an issue if there is something not documented. Even better, have a Gitter community where they can post questions. You can create an example to show how it's done. Those examples can then be added to the project. Done! 2. Decide on the common use cases for your library. Provide examples useful to someone getting started for each of the common use cases. What is a bad with example? 3. Looking at the source code, you have already written a bunch of comments. Those are documentation once you turn them into html. I'm for the comments to be documentation. But I am paranoid and do not like that the documentation generator should be granted write access to the repository.
Re: Postgres and other database interfaces
On Saturday, 24 February 2018 at 20:45:03 UTC, Joe wrote: On Saturday, 24 February 2018 at 18:56:23 UTC, Denis F wrote: It seems to me that this is a common misconception that it is possible to create a good universal tool for accessing the database in place of the many existing ones. I don't think what is needed a "good universal tool" but a good enough common interface. Python PEP 249 is very similar to what I've seen in the D libraries I've looked at: there is a Connection class of some kind, and a Cursor (or command or query) class, each with a set of well-defined (and generally not unexpected) methods: commit/rollback on the connection, execute/fetch/etc. on the cursor). PEP 249 also standardizes the exceptions and some datatypes. Currently in dpq2 all of these things are implemented except cursors (I think cursors became "unpopular" lately) It's not perfect, or universal enough, but I believe it allowed db development under Python to proceed at a faster pace than otherwise. If anyone really want to impliment your idea, at my first glance at the PEP 249 I had a feeling that this is work for time less than a 1-2 weeks. It can be a simple wrapper over dpq2, mysql-native, sqlite3, etc.
Re: Postgres and other database interfaces
On Saturday, 24 February 2018 at 18:56:23 UTC, Denis F wrote: Postgres quarantiees that result of query will be immutable libpq, of course, not Postgres itself.
Re: Postgres and other database interfaces
On Saturday, 24 February 2018 at 05:45:45 UTC, rikki cattermole wrote: There is plenty of desire to build a generalized SQL interface for Phobos. But somebody needs to do it and it won't be all that much fun to do. I want to dwell on this. It seems to me that this is a common misconception that it is possible to create a good universal tool for accessing the database in place of the many existing ones. SQL is something like BASIC from the 70-80s: there is no single standard, there are many dialects. And the differences are both syntactic and deep, for example, Postgres and Oracle differently interpret the ANSI standard concerning transactions. The same applies to the connection layer: some of the databases allow you to organize a gradual download of the results, some - feedback in the form of something like "events", etc. Also, Postgres quarantiees that result of query will be immutable and this is very useful, but some one another DB maybe not. At best, such a tool will be suitable for simple trivial things. On the other hand, needing for this is also not obvious - databases in real projects isn't switched usually every week/month because they are not interchangeable, except for some very simple cases. Usually RDBMS engine should be elected based on your requiriments before you start to use it.
Re: Postgres and other database interfaces
On Saturday, 24 February 2018 at 05:33:56 UTC, Joe wrote: 2. dpq2. Second most downloaded and built on top of derelict-pq. The "documentation" consists of a README listing the features and a single example, which appears to focus on support for JSON/BSON. Hi! Here is dpq2 and vibe-d-postgresql developer. The problem is that I do not know English very well. So,I think it's better not to write any documentation than to write the wrong one. PRs are welcomed! 3. vibe-d-postgresql. Third most downloaded and built on top of dpq2. Docs consist of a single example program.
Re: Typedef.toString?
On Friday, 23 February 2018 at 15:26:02 UTC, Meta wrote: On Friday, 23 February 2018 at 13:56:35 UTC, Denis F wrote: On Thursday, 22 February 2018 at 20:26:17 UTC, Meta wrote: find all this inclusions. Maybe it is need to implement simple toString method inside of Typedef struct? Or just disable it at all? Yes. I doubt this behaviour is intended, so it's likely an oversight in Typedef's implementation. Should be disabled also: factory opCmp opEquals toHash ? No, Typedef just needs a custom implementation of `toString`. I lean towards the idea to disable toString at all. Because if we wrap string type into it, string can leave Typedef wrapper unhindered.
Re: Typedef.toString?
On Thursday, 22 February 2018 at 20:26:17 UTC, Meta wrote: find all this inclusions. Maybe it is need to implement simple toString method inside of Typedef struct? Or just disable it at all? Yes. I doubt this behaviour is intended, so it's likely an oversight in Typedef's implementation. Should be disabled also: factory opCmp opEquals toHash ?
Typedef.toString?
Hello! After replacing native type by std.typecons.Typedef I am faced with fact what all typeDefValue.to!string was silently changed its output to output of Typedef struct itself. It was too hard find all this inclusions. Maybe it is need to implement simple toString method inside of Typedef struct? Or just disable it at all?
Re: Dlang remote junior developer jobs
On Monday, 9 January 2017 at 12:39:22 UTC, Bauss wrote: You could take a look at this list and perhaps send in your job application, resume etc. and perhaps they might hire you for remote work, but honestly it's a shot in the sky. https://dlang.org/orgs-using-d.html Also there's this thread posted by Walter which links to a site offering D jobs. https://forum.dlang.org/thread/o1gale$3cf$1...@digitalmars.com This link isn't work
Re: Dlang remote junior developer jobs
On Sunday, 8 January 2017 at 22:34:33 UTC, eugene wrote: Hello, everyone, could you share, please, your knowledge, where can i search D lang remote junior developer jobs? Hello! Same problem - I am need remote Dlang job. My Github contains my contacts: https://github.com/denizzzka/ And may be in 2018 it make sence to revert job section into this forum? Linkedin isn't contains any of D-related vacancy, but at past year I am was hired twice for per-project employment via Telegram chat and e-mail.
