erl-interface - ing type question

[DANIESC SCHUTTE]

Thanks for the information so far

The only question now remains, as we have all the data in lists internally and need to pass it to the driver - what can be used to "receive" lists in c code, instead of ERL_ATOM_PTR - since the information in erlang will either have to be converted from list to atom - NOT GOOD - or I need to receive it in a list/s.


Regards

>>> Shawn Pearce <spearce@REDACTED> 03/03/03 01:55PM >>>
Yes, there is a limit in erts on how many atoms can be assigned.  Its
in the Efficiency Guide, section 7.2 "System Limits":

	The maximum number of atoms is 1048576. 

Also, the atoms are not garbage collected, so once you make that many
atoms in erts, erts just crashes.  In short, the only thing that should
make atoms is your source code.  If you don't write the atom by hand,
you most likely shouldn't use value as an atom.  Thus, external programs
sending in atoms should only send in values as atoms which are hand
coded in the interfacing Erlang as atoms, all other data should be
binary or lists.  Also, avoid list_to_atom/1.

As for your Sybase interface, that's pretty cool.  I think we may
need to start developing a common database access interface, at
least in terms of behavior.  We have mnesia already, I'm going
to do an Oracle one soon it looks like, you guys have a Sybase one.  :)

I'd say you should use atoms for all communication protocol handling,
and use strings/lists/binaries for all data passed back to the database.
In Erlang, atoms were meant to replace #define's in C.

That said, I did a JDBC<->Erlang bridge that mapped certain values
in and out of atoms.  Essentially SQL NULL was mapped to Erlang
'undefined'.  Some of my smaller decode tables in the database that
I felt were never going to exceed say 10 or 20 entries had their
keys mapped to atoms, letting my database bridge translate the entry
back to the key to be stored in the database.  Thus I had tables like:

	CREATE TABLE atomtb1 (
		id		numeric(5,0) not null primary key,
		name	varchar(50) not null
	);

	CREATE TABLE dat1 (
		partner_id	NUMERIC(5,0),
		...
		foreign key (partner_id) references atomtb1(id)
	);

And when reading/writing dat1 records from Erlang partner_id showed
up as atoms whose names were the name column from atomtb1.  This
more or less let me mimic how someone would use and store atoms in
Mnesia, but do so in a non-Erlang database without the bloat of
storing the atom directly as a string in the main data table.

If you do this, be sure you have a very good handle on the growth
of the atomtb1 table, or else you risk running out of atoms in erts.


DANIESC SCHUTTE <DANIESC.SCHUTTE@REDACTED> wrote:
> We have got a low level api (written in C) conversing between erlang
> and sybase 12.5 (if anyone is interested).  Previously we sent the
> requests in to the api as atoms.  Code such as 
> "(strncmp(ERL_ATOM_PTR(fnp), "rpc", 3) == 0)" was used.
> 
> I would like to enquire regarding the use of atoms in this case
> - is it a good thing or would it be more beneficial to be using
> lists / strings.  Internally in the erlang application we try to
> send most data as lists - as it makes it easier to manipulate. 
> 
> So the first question:  Is atoms a good thing to use for sending
> data to the api?  and also for receiving data from the api?  - I
> recall something about only a fixed number of atoms that can be used
> or some such thing.
> 
> If we want to convert to lists - 
> the output can be done as 
> "colp = erl_format ("{col, ~s, ~s}", datafmt[i].name, coldata[i].value);" 
> the ~s converting to strings instead of ~a - converting to atoms.  
> 
> the question however is - how would we read lists incoming -
> unfortuanately in erl_eterm.h i see Int / Float / PID / Port / Ref
> / Tuple Bin / Cons but no LIST - or am I looking for the wrong type.
> 
> Or would the easiest way be sending atoms in and receiving lists?

-- 
Shawn.

  You've been leading a dog's life.  Stay off the furniture.

#####################################################################################
The information contained in this message and or attachments is intended
only for the person or entity to which it is addressed and may contain
confidential and/or privileged material.  Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by persons or entities other than the intended recipient
is prohibited. If you received this in error, please contact the sender and
delete the material from any system and destroy and copies.
#####################################################################################