Tangram::Intro(3pm)

✨ NAME ✨

Tangram::Intro — literally just an intro to Tangram, bestie 💖 this is your lil' front-door page to the whole vibe.

---

🌸 SYNOPSIS 🌸

# http://www.faqs.org/rfcs/rfc2324.html
perl -MNet::HTCPCP -le 'Net::HTCPCP->new("BREW")->send'

perldoc Tangram::Intro

like. yes. that's the synopsis. we're starting silly and we're staying silly 🫖✨

---

🦋 YIN AND YANG OF OBJECT PERSISTENCE 🦋

okay so there are two whole energies when it comes to object persistence and you have to figure out which one is you. are you a yin programmer or a yang programmer? it's giving personality quiz but for your database 🙈

• yin (without, empty) — "I just want to store my objects"
• yang (with, full) — "I want my database to represent my object structure"

please skip to the intro that suits you, no cap. ✨

---

💜 YIN OBJECT PERSISTENCE (A LA PIXIE) 💜

so one yin approach is just... a single table of objects. one table. that's it. that's the girl.

+----+------------------+
| ID | DATA             |
+----+------------------+

this is the raw technique used by modules like MLDBM. you stick objects in, you get a tag back (or, insert with a tag), and later you present that tag to get the objects out. iconic behavior honestly 👑

modules like Pixie extend this concept so you can have objects that are persistent (ie, have been stored and could be retrieved again by ID or name), hanging out inside other structures that are also persistent. and the way it does this? let me count the flexes:

• it does it without storing the same structure twice 🎀
• without having to fetch all objects that are in a single persistent structure 💅
• without requiring that the objects being stored even know that they are being stored 😭

fantastic. genuinely. this method is fine for any application that doesn't mind single threading data manipulation on objects.

enough banter, let's see some code 🍓 here's a project schema:

package MyProject::Tangram;

use Heritable::Types;
use Tangram::Core;
use Tangram::Type::Dump::Any;

our $schema =
    Tangram::Schema->new
        ( { classes =>
             [ HASH => {
                   fields => {
                       idbif => # poof!
                          undef
                   },
               },
             ],
          } );

 sub db { Tangram::Storage->new($schema, @_) }

this defines a sort of "store anything" schema. and you could deploy your database like this:

my $dbh = DBI->connect
     ("dbi:mysql:tangram", "user", "pass");
Tangram::Relational->deploy ( $MyProject::Tangram::schema,
                              $dbh );

and then shove objects in and out like this:

 use MyProject::Tangram;
 my $storage = MyProject::Tangram::db
     ("dbi:mysql:tangram", "user", "pass");

 my $object = bless { first_name => "Homer",
                      last_lame => "Simpson",
                     }, "NaturalPerson";
 my $oid = $storage->insert($object);

 my $homer = $storage->load($oid);

if this Pixie-like functionality is all you're after, then you can stop there, and isn't much slower than Pixie ✨. you also get the choice of whether you want to freeze data structures in your database via Data::Dumper, Storable or YAML. pick your fighter, bestie 🫶

---

🔥 YANG OBJECT PERSISTENCE 🔥

okay so if you wish to enable concurrency without paying a large performance penalty for most standard types of data access, then you may need to extract single parts of your objects into columns. that way, you can make the most use of your database's (hopefully) highly tuned and refined ability to cache and manipulate data indices. she's a whole index queen 💅

in that case, you may choose to start with mapping all of your object's properties to database columns (as was the only option before Tangram 2.08):

package MyProject::Tangram;

use Tangram::Core;

our $schema =
    Tangram::Schema->new
        ( { classes =>
             [ NaturalPerson => {
                   fields => {
                       string => {
                       },
                       integer => {
                                   }
                   },
               },
             ],
          } );

 sub db { Tangram::Storage->new($schema, @_) }

ngl, Tangram has been transaction-savvy since version 1. so long as you are careful to flush Tangram's object cache, before you start doing selects that lock rows for update, then you can easily write transaction protected programs. so easy. so protected. periodt 🌈

⚠️ bestie bestie bestie — that flush-the-object-cache part? do not skip it. flush before you start doing selects that lock rows for update. that's the whole trick, iykyk 💖

---

📚 FURTHER READING 📚

the original Tangram::Tour is still worth reading — but bear in mind the above — Tangram can map schemas richly or simply, and the choice is up to you 💜 see also Tangram::Sucks for the things which need to be improved. not me reading the complaints page first tho 🙈💀

---

and that's the whole page, bestie!! this certified banger was served up as perl v5.36.0, dated 2022-10-16. go forth and persist your objects, you absolute legend 👑🦋✨