I understood that it will have the full context of the data on your phone, in order to be ,,useful”.
We are yet to see if that means only the data you’ve invoked ai features for, or totality of your emails, notes, messages, transcripts of your audio, etc.
Meanwhile, a company I used to work at keeps on using self hosted MantisBT.
Its maintenance takes like 2 engineer days per year total, if that.
Its initial setup with all the plugins ( of note are those for project management and release tracking) and integrations (e.g. git) took one engineer week if I remember correctly.
And it works just fine for 7 years now, to the point that the only advantage of Jira I see is a slightly fancier looking interface for the regular user. Whilst costing peanuts.
I even prefer the old school Mantis BT look and feel.
It will be taken to a next level by the AI, both in terms of defensive and offensive capabilities.
We already have interesting startups and projects dealing with defence aspect.
I’ll note glog.ai as something I’ve seen most recently in this domain - it entails a machine learning algorithm that classifies SAST output and assists the developer in triage of potential vulnerabilities.
SELECT
u.*,
(
SELECT
JSON_AGG(p)
FROM (
SELECT p.*
FROM purchases p
WHERE p.user_id = u.id
LIMIT 10
) p
) AS purchases
FROM users u
JOIN purchases p ON p.user_id = u.id
GROUP BY u.id
LIMIT 100;
Starting queries with from - what is the benefit of that beside personal preference?
And you can simply use a cte or a view instead of a field set.
“SQL is particularly inflexible in terms of control over response: A query result is always a set of tuples. A query is incapable of returning a rich structure that is aligned with how the application needs to consume the result. ORMs solve this partially at best at the cost of hiding the capabilities of the underlying database. They also obscure the structure of generated queries, making it difficult to understand the resulting performance implications.”
The ORMs or later mentioned GraphQL are not the only approaches to solving object-relational impedance mismatch.
SQL is perfectly capable of serializing sets of tuples to XML (part of the SQL standard), and most SQL RDBMS implementations now support working with JSON data.
Serializing using SQL to XML and in the past couple of years to JSON, and deserializing the said XML/JSON to an object model in the programming language of choice is something I’ve seen used fairly often in my career.
Heck, I’ve even seen entire business logic for a very complex system implemented via thousands of stored procedures that always returned XML. Prior to 2010, this was not the blasphemy it is made to be today…
So to reiterate my point, SQL is not inherently as inflexible as it was made to be here, thus neither ORM nor GraphQL are a necessity for dealing with SQL output inflexibility (and both can be very useful tools, as always, completely depending on the context).
We are yet to see if that means only the data you’ve invoked ai features for, or totality of your emails, notes, messages, transcripts of your audio, etc.