Tangram::Sucks(3pm)

💖 Tangram::Sucks 💖

okay bestie, so this is Tangram::Sucks — a whole manual page that is literally the Tangram devs sitting down and going "here's everything about us that needs work." the audacity, the honesty, the self-awareness? iconic. 🫶

---

✨ NAME ✨

Tangram::Sucks — the tea is: what there is to be improved in Tangram. 💅

---

🌸 DESCRIPTION 🌸

so Tangram took a concept that Java-land programmers know very well and just... took it to its logical completion. slay.

this document is Tangram's own coders trying to summarise the major problems baked into the design, describe the cases where the Tangram metaphor just does not work well, and list out the long-standing TO-DO items. it's giving "we're our own worst critic" and honestly? respect.

---

🎀 DESIGN CAVEATS 🎀

• query language does not cover all SQL expressions — okay so there's no underlying fault with the query object metaphor itself, but rn there are like, SO many queries that simply cannot be expressed in current versions of Tangram. and adding new parts to the language? not easy. at all. 🙈
• some loss of encapsulation with queries — you could argue this isn't even a problem, tbh. after all, adding properties to a schema of an object is basically the same as declaring them "public", bestie.

some people banter on about data access patterns, which the Tangram schema represents. but OO terms like that are usually just treated as buzzwords anyway. 💀

---

🔥 HARD PROBLEMS 🔥

• partial column select — this optimisation has some serious dangers associated with it. genuinely.

it could either be

and that's it. that's where the sentence ends. no cap. the original just... stops. main character exit. 💀✨

• no support for SQL UPDATE — it may be possible to write a version of $storage->select() that does this! and it would look something like:

  $storage->update
      ( $r_object,
        set => [ $r_object->{bar} == $r_object->{baz} + 2 ],
        filter => ($r_object->{frop} != undef)
      );

• no explicit support for re-orgs — the situation where you have a large amount of schema reshaping to do, with a complex enough data structure, can turn into a fairly difficult problem. like, lowkey a whole ordeal.

you can have two Tangram stores with different schema and simply load objects from one and put them in the other — however, the on-demand autoloading combined with the automatic insertion of unknown objects will result in the entire database being loaded into core if it's sufficiently interlinked. so. yeah. be careful. 😭

• replace SQL expression core — the whole SQL expression core needs to be replaced with a SQL abstraction module that's a little better planned. for instance, there should be placeholders used in a lot more places where the code just sticks in an integer etc. 🙃
• support for `large' collections — where it's impractical or undesirable to load all of a collection into memory, when you're adding a member and then updating the container, it should be possible to do this without loading the entire collection into memory. chef's kiss.

this could actually be achieved with a new Tangram::Type. 💅

---

💜 MISSING FEATURES 💜

• concise query expressions — for simple selects, the query syntax is just too long. getting remote objects should take less code. fr fr.
• non-ID joins — we can't join on anything except "ID" values. 🥲
• tables with no primary key — we can't map tables unless they have a primary key, and it has to be called "id" (or, at least, the same name as the rest of the schema).
• tables with multi-column primary keys — we can't map tables when they have multiple primary keys. well, you can, but only if you make a view with an ID column that's functionally derived from the multi-part keys. but that sucks. 💀
• tables with auto_increment keys — these suck, but Tangram could still support them without requiring schema hacks.
• **tables without a `type' column** — the 'type' column is unneeded for base tables which do not have subclasses.
• tables with custom `type' columns — for mapping schemata where some clever person has invented their own special way of representing types using discrete column values. 👑
• tables with implicit (presence) `type' columns — it should be possible to infer the type value based on knowledge of the schema, and the tables which have rows.
• fully symmetric relationships — back-refs are read-only. that's the whole vibe and it's not the one we want. 😔
• bulk inserts — inserting lots of similar objects should be more efficient. right now it generates a new DBI statement handler for each object, which is giving wasteful, honestly. 🙈
• `empty subclass' schema support — you should not need to explicitly add new classes to a schema if a superclass of them is already in the schema. 🦋
• warn about column redefinitions — defining a column twice should be an error. reported by Mark Lawrence. shoutout Mark, the realest one. 🫶

---

aaaand that's the whole page, bestie 💖 no notes, only facts, and every single one of them is still in here, periodt. this one's from perl v5.36.0, dated 2022-10-16, and it lives in the User Contributed Perl Documentation section as Tangram::Sucks(3pm) — go off, king. 🌈⭐🎀