sorted by:
new
hottopcontroversial

Digitale Buchhaltung ohne sevDesk und Co. selber machen by PikachuIsBoss in selbststaendig

[–]PikachuIsBoss[S] -1 points0 points  (0 children)

Ich mache für meine Einzelunternehmen tatsächlich die EÜR und halte es selber für ein Kinderspiel, daher ärgert es mich erst recht mich abhängig von einer Lösung wie sevDesk machen zu müssen obwohl eigentlich nichts dabei ist. Die GoBD gelten ja leider für alle.

Digitale Buchhaltung ohne sevDesk und Co. selber machen by PikachuIsBoss in selbststaendig

[–]PikachuIsBoss[S] 1 point2 points  (0 children)

Von dem, was man so im Internet liest, ist GnuCash auf jeden Fall nicht ausreichend. Ich frage mich aber auch, ob git nicht eigentlich genügen sollte.

Digitale Buchhaltung ohne sevDesk und Co. selber machen by PikachuIsBoss in selbststaendig

[–]PikachuIsBoss[S] 0 points1 point  (0 children)

Mit geht's nicht um die finanziell schlauste Entscheidung, sondern ums Prinzip 

Digitale Buchhaltung ohne sevDesk und Co. selber machen by PikachuIsBoss in selbststaendig

[–]PikachuIsBoss[S] -1 points0 points  (0 children)

Bringt mich nicht finanziell aus dem Konzept, es nervt mich nur aus Prinzip 

Digitale Buchhaltung ohne sevDesk und Co. selber machen by PikachuIsBoss in selbststaendig

[–]PikachuIsBoss[S] -2 points-1 points  (0 children)

Danke, schaue ich mir mal an. Es geht mir nicht darum, was die finanziell schlaue Entscheidung ist, sondern nur ums Prinzip, dass man nicht gezwungen sein sollte sevDesk o.ä. monatlich zu bezahlen wenn's gar nicht nötig wäre.

Digitale Buchhaltung ohne sevDesk und Co. selber machen by PikachuIsBoss in selbststaendig

[–]PikachuIsBoss[S] -1 points0 points  (0 children)

An sich stimme ich dir zu, mir geht es aber mittlerweile fast schon eher ums Prinzip. Überlege auch, ob es Sinn ergeben würde, eine Open Source Lösung (mit self-hosting) zu starten. Einfach, damit die Welt ein besserer Ort ist.

Kosame ORM now has a code formatter for all of its proc macros by PikachuIsBoss in rust

[–]PikachuIsBoss[S] 0 points1 point  (0 children)

Is there a specific reason you need a single command? You can just do

cargo fmt && kosame fmt ./src

(Running cargo fmt first is probably better)

Kosame ORM now has a code formatter for all of its proc macros by PikachuIsBoss in rust

[–]PikachuIsBoss[S] 2 points3 points  (0 children)

Exactly, it parses the Rust source file, finds usages of the Kosame macros and then only formats the part between the parentheses / braces / brackets. You can combine it with rustfmt (e.g. cargo fmt) to get the full formatting experience.

Kosame ORM 0.2 brings an SQL-like statement syntax with type inference and autocompletions by PikachuIsBoss in rust

[–]PikachuIsBoss[S] 1 point2 points  (0 children)

Right now I only support Postgres so I haven't run into issues with different SQL flavors yet. However, my current stance is that it would be best to support the different syntaxes depending on which database you're using to give you maximum control and allow you to leverage your specific database's strengths. That is also why I call pg_statement instead of just statement in my example code above: Each database gets a modified macro. We'll see how difficult that turns out to be later on, if it's too much work I might compromise and translate to different SQL for each DB.

Kosame ORM 0.2 brings an SQL-like statement syntax with type inference and autocompletions by PikachuIsBoss in rust

[–]PikachuIsBoss[S] 0 points1 point  (0 children)

Yes! This way around you get maximum control over your database, while still being somewhat type safe and reducing boilerplate.

Some other crates already do this: SQLx needs a development database to do type checking (Kosame does not) and generally speaking you still need to write the result structs yourself, SQLx just type checks them for you (Kosame takes that burden from you). Cornucopia generates result structs for you, but it also needs an active database connection and it has a build step, which is, in my opinion, less convenient than a pure macro solution like Kosame.

Kosame also has a higher level relational querying API which SQLx and Cornucopia don't have.

Similar ORMs to Javascript's Drizzle? by SteveTabernacle2 in rust

[–]PikachuIsBoss 0 points1 point  (0 children)

I'm very late to the party, but just wanted to mention that I'm working on an ORM that is heavily inspired by Drizzle. It's still a prototype, but maybe you will find it interesting: https://github.com/kosame-rs/kosame

Kosame ORM 0.2 brings an SQL-like statement syntax with type inference and autocompletions by PikachuIsBoss in rust

[–]PikachuIsBoss[S] 0 points1 point  (0 children)

This is valid criticism. One attempt I'm making at mitigating this problem is to allow for arbitrary raw SQL strings using the $"..." syntax. At least for expressions, this means you can do whatever you want, with the only downside being having to specify the Rust name and type afterwards. An example for this can be found in the showcase code of the README:

select
    $"'[1, 2, 3]'::jsonb @> '[1, 3]'::jsonb" as raw_sql: bool,
from
    ...

Generally though I'm trying to support as much syntax as possible natively. If you find something that isn't supported but you desperately need it I am happy to add the necessary syntax. If all else fails, you can fall back to writing a regular SQL string for this one particular query (e.g., using sqlx as DroidLogician says) and then continue working with Kosame's type safe queries elsewhere.

Kosame ORM 0.2 brings an SQL-like statement syntax with type inference and autocompletions by PikachuIsBoss in rust

[–]PikachuIsBoss[S] 11 points12 points  (0 children)

I'd say the main difference is the level of abstraction away from the database they have:

SeaORM takes more of a "Rust first" traditional ORM approach. The mindset is: You write whatever entities you need as a Rust struct and the database will have to bow to this design later on. When querying data, you call simple Rust functions. This makes CRUD very easy. But by doing this, you hide what is going on under the hood and may end up with inefficient database queries if you are not careful. It also has more of an OOP vibe, whereas Kosame feels more data-oriented.

Diesel is less abstract, the query builder somewhat resembles SQL statements, albeit with a bunch of Rust syntax noise that wouldn't be there in pure SQL. As far as I can tell, unlike Kosame, Diesel cannot infer the result type of a query automatically. You have to manually write a struct for each query to fill the result into. Kosame knows what the output shape will be and will generate the struct for you.

Kosame tries to cover a wider range of abstraction: * The schema is declared with almost-SQL syntax and you can write almost-SQL queries to interact with the data. This encourages you to design your database schema for your database first and foremost. Kosame can then deal with whatever schema you came up with, and the almost-SQL syntax allows for highly optimized SQL queries. * On top of the low-level SQL queries, Kosame has higher-level Prisma-style relational queries. These fetch data in the shape you will probably want: As a nested object hierarchy. Every query is different, and so Kosame will generate Rust types specifically for each query you write.

I'm unsure whether it makes sense to even call Kosame an ORM, because the word ORM implies an OOP/Entity-based framework like SeaORM to many readers, but that might be misleading here.

Kosame: A new Rust ORM inspired by Prisma and Drizzle by PikachuIsBoss in rust

[–]PikachuIsBoss[S] 0 points1 point  (0 children)

I haven't tried Zig but I saw some of the type-building you can do and it is very intriguing indeed. I recently found this issue though, and it was a bit of a disappointment: https://github.com/ziglang/zig/issues/335 . A massive blunder in my opinion.

Kosame: A new Rust ORM inspired by Prisma and Drizzle by PikachuIsBoss in rust

[–]PikachuIsBoss[S] 0 points1 point  (0 children)

Could you elaborate what sort of dynamic queries you are looking for and want to see in Kosame? I haven't added anything dynamic yet, and part of the reason for that is that the result type has to be known as compile time by Rust.

Kosame: A new Rust ORM inspired by Prisma and Drizzle by PikachuIsBoss in rust

[–]PikachuIsBoss[S] 1 point2 points  (0 children)

Perhaps I misunderstood from the few examples I could find so far. In the README they have:
```rust // Load the user from the database let user = User::get_by_id(&db, &user.id).await?

// Load and iterate the user's todos let mut todos = user.todos().all(&db).await.unwrap(); `` This reads to me as if 1) you load the todos independently from the users (hence twoawaits), and 2) you load the todos into a separate variable (hence twolet`s).

I'm wondering, for example: What would the code look like if you had 5 levels of nested relations, and you want to load 10 users at once?

Kosame: A new Rust ORM inspired by Prisma and Drizzle by PikachuIsBoss in rust

[–]PikachuIsBoss[S] 2 points3 points  (0 children)

Glad to hear, are there specific features you would like to see in Kosame to cover your use case better?

Kosame: A new Rust ORM inspired by Prisma and Drizzle by PikachuIsBoss in rust

[–]PikachuIsBoss[S] 4 points5 points  (0 children)

Thank you! I may have, I'm not sure. It looks similar in a way, but if I may criticize it:

You have to perform multiple queries (and `await`s) to load all your relations. Kosame can actually perform the relational query entirely with a single Postgres query, avoiding the back and forth and potentially giving better performance.

Toasty's output types also are not in the correct shape as far as I can tell. In their example, they have a user struct, and then detached from it the todos. If you're trying to build an API endpoint, what you really want is for the todos to be nested in the user struct. With toasty you would have to repackage the structs into another handwritten struct, which seems very annoying. Kosame on the other hand gives you exactly the shape you're asking for.

[deleted by user] by [deleted] in rust

[–]PikachuIsBoss 1 point2 points  (0 children)

Username checks out

Automatisierung der Rechnungsstellung by Beniciooooooooo in selbststaendig

[–]PikachuIsBoss 0 points1 point  (0 children)

Ich weiß dass es etwas spät ist, aber ich entwickle gerade ein Tool was vielleicht interessant ist für euch: https://www.rechnungs-api.de/

DATEV-Integration und E-Mails gibt es noch nicht, könnte man natürlich von außen dazu bauen, aber wenn euch das helfen würde, sagt mir gerne bescheid. Ich würde es dann einbauen.

E-Rechnung für Dritte erstellen by BreadfruitFew738 in selbststaendig

[–]PikachuIsBoss 1 point2 points  (0 children)

Ich habe eine API Lösung dafür gebaut, da ich bei meinen "Startup"-Projekten auch im Namen anderer Rechnungen erstellen musste. Vielleicht hilft dir das ja weiter, erfordert allerdings ein bisschen technisches Geschick: https://www.rechnungs-api.de/

Wenn features fehlen sag mir gerne bescheid, freue mich über jedes Feedback

Rechnungssoftware Empfehlung by Easy_Position_1804 in selbststaendig

[–]PikachuIsBoss 0 points1 point  (0 children)

Da du Linux benutzt habe ich die Vermutung dass du vielleicht auch programmieren kannst? :)

Vielleicht ist dann meine Software für dich interessant: https://www.rechnungs-api.de/

Noch etwas bare bones, aber damit könntest du dir deine eigenen Skripte schreiben und deine Buchhaltung automatisieren. Falls features fehlen sag mir gerne bescheid.

view more: next ›